w3c / wai-easy-checks Goto Github PK

https://www.w3.org/WAI/EO/wiki/Easy_Checks#e1

Firefox still has no title bar on MacOS and will likely never get one, so my proposal is to change

Firefox: If the title bar isn't displayed you might be able to display it by pressing: Alt+V, T, M (or right-mouse click in the empty area after the tab and select Menu Bar).

to

Firefox, on Windows: If the title bar isn't displayed you might be able to display it by pressing: Alt+V, T, M (or right-mouse click in the empty area after the tab and select Menu Bar).

Then this is resolved in my view.

Testing with color deficits on a high resolution monitor, IMHO, I found a lack of intuitive distinction amongst

,

, and

. I recommend increasing the differentiation in size, and/or perhaps changing font weight.

We should vanquish this word unless specifically discussing pointing devices that have a button.
I suggest we use the word "select" instead.

Just for reminding me :-)

moved the following into this issue from the wiki page:

that the third sentence under "Background" could be clearer. Currently: To check a couple details, you need to see the visual page or hear audio. Suggest: To perform a couple of the checks, you need to see the visual page or hear audio. {Bim}

[high] Please add a sub-bullet under WCAG-EM, to refer people to the WCAG-EM Report Tool (https://www.w3.org/WAI/eval/report-tool/). It can be very helpful for this audience to know right away that there is practical tool to guide them through the WCAG-EM specification.

Noticed this @@:

Automatic captions are not sufficient for accessibility because they are not accurate enough. For example, in YouTube, if only "automatic captions" are listed (as in the image above), there are no sufficient captions and the video is not accessible. Captions in the specific language need to be listed. [@@ say more ?]

Priority: medium
Current text: "More robust evaluation is needed to evaluate all issues comprehensively"
Suggested text: "More robust evaluation is needed to make conclusive statements" or "More robust evaluation is needed to address more issues and make more conclusive statements"
Rationale: Even if one does not want to evaluate all issues, the results from these checks may not be conclusive. That is, the limitation of this resource is not only the breadth of coverage but also the depth.

In general font size seems too small but especially:

www.w3.org/WAI/demos/bad/before/home

Add instructions for doing the checks with Chrome -- and provide a filter for it per #9

WCAG mentions audio & video as media alternatives in 1.2.3 & 1.2.8.

As multimedia refers to text, print media as well, I think we can be consistent here using the same terminology as WCAG. Please consider this suggestion to keep the key terminologies consistent across.

Another reason all texts do not resize is because of the use of mix of font-size measures (both absolute and relative font-size) in the same page. Only relative fonts can be resized using browsers text resize. Others need assistive technology or browser zoom.

Absolute font sizes:
mm | cm | in | pt | pc | px

Relative font sizes:
em | % | ex | named font-size

This is a comment related to Easy Checks - A First Review of Web Accessibility

I notice that at least the first illustrations (under Page Title) is slightly smaller on the github version than the live version. I worked for hours trying to maximize this space (the width, that is), so unless there is some compelling reason to have shrunk it (and possibly others) it would be better to return it (them?) to the original size.

This is feedback emailed to Sharron, Eric, Shawn, Shadi on Sept. 8. I have not heard back from anyone, so am transferring this to a place it's less likely to get lost. (The illustration numbers refer to the table at the end of https://www.w3.org/WAI/EO/wiki/Easy_Checks_-_Illustrations.)

Three items of feedback so far.

1. The github version that I'm seeing (which may be a bit broken) does not have expand / collapse buttons. IMO this is an improvement -- especially when looking at illustrations on smaller screens. So hopefully that's something that is in the works. Is it a change that's being planned for?
2. Illustration #18 - Contrast Ratio (E "To check contrast with IE WAT")
   My memory (backed to some extent by the illustrations wiki) is that we had agreed not to use that illustration at all. It looks bad (distorted by squishing) in the live version on a smaller screen -- but fine in the GitHub draft. That said I still think it's a wasted use of illustration. There are other more complicated, less IE-centric things that aren't illustrated and could use illustrations more. It's a question of priorities and balance -- and this is the kind of thing we worked through as a team -- so we would illustrate what most needed it, but not everything.
3. Illustration #20 - Resize text - Group of three images showing (1) normal-size text, (2) larger text re-wrapping to fit the width, (3) larger text creating horizontal scrolling.
   These were supposed to not stack in most browsers at full width but they are in live as well as draft (that's in Chrome on a Mac). I still have the code in my sandbox. Eric -- do you want me to dig back through my old code and let you know what's gone awry with this illustration?

How was this discussion between Eric and Shawn resolved?

• (For example, appropriate text alternative for a search button (search) would be "search", not "magnifying glass".)
• This text is copied and pasted from the page and the magnifying glass is replaced with the alt text “search”, but it should read “magnifying glass” – even better would be a button with a magnifying glass and the alt text “button with magnifying glass”. {Eric}

should we add links to appropraite sections of the tutorials under the various 'learn more about' sections?
eg. https://www.w3.org/WAI/tutorials/page-structure/headings/ for Headings

A while ago there was some strong opinion that we need to have clearer disclaimers on Easy Checks. We have the following open issue:

[Sharron updating] disclaimer — Add note about not definitive at the bottom of each section, per Suggested: More visible, stronger this is not definitive, have to do more... below. Need to finalize wording and visual appearance.

Discussion of this is at https://www.w3.org/WAI/EO/wiki/Easy_Checks#Suggested:_More_visible.2C_stronger_this_is_not_definitive.2C_have_to_do_more...

@vuxcaleb Caleb took a pass at implementing what he thought was the conclusion from that discussion. It is implemented in this draft after the TOC.

Please scroll up to see it in context - and also follow the link in it.

EOWG feedback encouraged...

(/me has opinions but will wait to share them until others have a chance to chime in :-)

It seems that WebAIM removed images that are referenced in EasyChecks - these are all broken now :(

Testing with color deficits on a high resolution monitor, IMHO, I found a lack of intuitive distinction amongst h2, h3, and h4. I recommend increasing the differentiation in size, and/or perhaps changing font weight.

priority: strong suggestion for future versions
location: Image text alternatives ("alt text")
current wording: We only discuss the alt attribute which implies if that's not used, the image fails.
suggested revision: We should include, even if only in a couple of lines, other options for alt text (aria-label, etc.)
rationale: incomplete - possibly inaccurate info - without this.

Currently Contrast ratio is listed under the easy checks for Text. It might be overlooked as Contrast ratio does not apply to images / infographics.

I think we need to include a line to include images as
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 as stated in 1.4.3 Contrast (minimum)

In the What to check for section, the below statement seems a bit ambiguous:
Web pages should also have a minimum contrast by default: a contrast ratio of at least 4.5:1 for normal-size text.

CSS font-size property supports the below font sizes:
font-size: medium | xx-small | x-small | small | large | x-large | xx-large | smaller | larger | length | initial | inherit;

Browsers support : Very small | smaller | medium | large | very large

I think we need to be a bit more clear here as some websites uses 10pts, some uses 12pts.

Hi,

Incrementally increase text-only zoom:
In Windows, press Ctrl+[+] (the control key and the + key at the same time) 4 times
On Mac, press command+[+] (the Command key and the + key at the same time) 4 times

If the font-size is declared in relative units (%), it takes 5 increments to reach 200% in Chrome and 6 increments in Firefox according to my tests. I used this page and p{font-size:100%;}.

I see where the expand and collapse buttons have been added to the github version. Thanks so much. However, they are wonky because the + and - graphics aren't showing up. As best I can tell it's not affecting the illustrations, but if that can be fixed it would be one less variable to deal with.

That said, for the sake of giving the illustrations much needed breathing room, I actually preferred the version without the expand and collapse buttons. Personally I find those buttons more annoying than helpful, but that's a usability issue and this is just my experience.

However the issue of giving illustrations more space is different. So I'm strongly in favor of getting rid of the expand / collapse buttons in the next version. If others think it's important to hide, then there are other ways to do this that do not require an indent (and thus loss of width) for the hidden content when it is displayed.

Suggestion for check from Gregg V.: https://lists.w3.org/Archives/Public/wai-eo-editors/2015Jul/0044.html

Draft (thanks to Sharron!) at: http://www.w3.org/WAI/EO/Drafts/eval/checks#flash

Does this potential new check meet our Criteria for including a check? See: https://www.w3.org/WAI/EO/wiki/Eval_Analysis#Criteria_for_checks

If yes, comments on draft wording?

https://validator.w3.org/checklink?url=https://www.w3.org/WAI/eval/preliminary

https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.w3.org%2FWAI%2Feval%2Fpreliminary

I am reviewing the document in Chrome and Firefox and I'm not getting [+] or the ability to hide sections. Has this functionality been deleted or to be added in the latest version?

Click headings with [+] buttons to get hidden information

Some sections of this page might not apply to your situation, for example, they are for a browser you don't have, or you only need to read them once. These sections are hidden by default so they don't clutter the page. You can expand them to see the information. The headings of hidden sections have a plus button [+] before them. Screen readers will say something like: "graphic, expand this section". To get the hidden information, click the button or click anywhere on the heading.

The sections below all have hidden information under expandable headings. The first time you read this page, we recommend that you expand the headings of these five sections and read them.

No line breaks after images. Hence the bulleted lists are not aligned well. Issue happens in Chrome 55, Firefox 45, IE 11 - Tested on Windows 7 laptop

From @AndrewArch

re the Resize text check, can we say anything about page that don't 'pinch-zoom' on mobile devices? Maybe record in backlog for next review?

Shawn agrees to consider adding this.

The new checks for Moving, Flashing, or Blinking Content that we have been working on (1, 23) have been integrated into a draft of the document so we can review them in context. Please skim the Easy Checks document overall to re-familiarize yourself with how the other topics and checks are presented.

Two options are presented, A & B below:

• A. Two separate topics:
  • Flashing or Blinking Content
  • Moving Content
• B. One combined topic:
  • Moving, Flashing, or Blinking Content

This is a comment related to Easy Checks - A First Review of Web Accessibility

priority: Important
location: "Keyboard instructions: Ctrl for Windows, cmd for Mac" section
current wording: Some of the keyboard instructions are different for Windows and Mac; for example, "Ctrl" verses "cmd"
suggested revision: Some of the keyboard instructions are different for Windows and Mac; for example, "Ctrl" versus "cmd" in:
rationale: wrong word

I was never comfortable with including IE WAT instructions, but went along with this two years ago given my lack of expertise in a11y testing. In the intervening two years my discomfort is greater. Most front end developers I know use Mac. Certainly almost all of our thought leaders/figureheads do. In many ways this is a direct result of IE's track record with CSS -- especially IE6. I hear that Edge is much better, but like most of my colleagues, I gave up long ago and only use IE to test sites I'm coding to be sure they look OK to IE users.

I realize the audience for Easy Checks is much broader than developers, but according to sites such as StatCounter (http://gs.statcounter.com/) (1) Chrome is 3 times as popular and (2) IE is tied with Firefox which is available on both PCs and Mac.

To me using IE WAT has a quality of endorsing Windows. In addition, with developers (and possibly others) such frequent reference to IE runs the risk of losing respect and traction -- giving one of those instant all-important bad first impressions.

In other words, in my opinion it's time to either relegate IE WAT tests to a separate page or pull them altogether. If we pull them, that will save a hefty amount of work on illustrations. I'm just about through with the inventory, and the majority of illustration issues with the live site seem to be for IE WAT.

[bug] The characters "/cmd" in this bullet appear in a different color. This is confusing and also difficult to read. Seems like a bug?

Reminder for myself. I should be able to look into it on Wednesday (December 14, 2016).

In re illustration 30 (the second of the Keyboard access and visual focus images), in March 2014 Shawn thought it important to replace. I'm not certain I understand what she wants, but am attaching my best guess.

Note that as long as I was editing the image, I balanced the borders. I find this balance less distracting.

This is a comment related to Easy Checks - A First Review of Web Accessibility

[medium] In https://w3c.github.io/EasyChecks/#using we only refer to using Chris Pederick's toolbar in Firefox. While we talk about Firefox in all the examples, the toolbar is also available in Chrome and Safari and the approaches described work equally well. As such I strongly recommend (soon if not now) that we add a link to https://chrispederick.com/work/web-developer/ where all versions are listed and can be download for any of these three browsers, and add some words that the techniques apply to the use of the web developers toolbar in any of these browsers too.

Editor's discretion for now or later

Review the Completion Plan wiki page to make sure that everything is either already done, or add it as an Issue in GitHub. And update the Completion Plan wiki so each issue shows with either [done] or [GitHub Issue].

Currently there is one page that includes instructions for both a Firefox toolbar and an IE toolbar.

Idea: User can pick one and get only the instructions for that one.

Other ideas for filters:

• mouse or keyboard instructions (this would simplify the info a fair bit since now there are both)
• Mac or PC

All of the illustrations need careful review. With the last update of Easy Checks live that involved illustrations, some issues fell between the cracks. That was 1.5 years ago. I can go back through my notes illustration by illustration, but before I invest that kind of time, I would like some sort of methodology in place.

Doing a table that tracked them was great, but doing it in the Wiki was crazy-making. Can we use a shared Google Drive spreadsheet? Or is there some other reasonably easy way to keep track of who has reviewed what and the status of each illustration?

Thanks

[minor] This title does not really read well to me. Maybe "Explore Further" or such?

Also, I think the "encourage" aspect assumes too much and needs explanation in the text. Maybe something brief like "The following resources can help you or someone else in your team carry out further analysis".

The problem with Illustration 20 (Resize text, group of 3 images) on the live site is the image width stated in the image element. On the live site they are the actual width of the image. In the original code, they were reduced proportionally. Somehow this got lost in the last minute dash of March 2014.

I've put the code comparison in a text file and tried three times to attach it to this comment, but GitHub keeps saying "Something went really wrong, and we can’t process that file. Try again." I think 3 times is enough. I'm putting it on DropBox. BTW, for now I'm not forking the code yet given the issues in variation between GitHub and the live site and the impact that has on illustrations.

Also, in re the @@note in the figcaption for the original code, let me know if you want me to resize the images themselves. For whatever reasons, they actually look sharper in the original draft (my file 11a.php).

In looking at issue #18 it occurred to me that most of these missing images have alt="", which seems incorrect to me - I think they are mostly informative images (icons that indicate some information, not pure decoration).

[later] should we add the simple check of clicking on a label to see if it pulls focus into the element?

Also, we should recommend that any non-text 'required' indicator ["such as asterisks (*)"] is explained. That said, most usability folk these days recommend using text rather than symbols. We should also probably note that the trend now is to minimise the optional fields and, as there will be less of them, and to flag the 'optional' ones.

Users can Expand All instructions for one tool and not the other.

Priority: Medium

Location: Flashing or Blinking content

Suggested:
Include an example image of what three flashes per second looks like. This could be a simple animated GIF (or SVG?!). This may need to be hidden behind an expand/collapse so people can chose specifically if they want to see it.

Rationale: It is arguably difficult to know what three flashes per second looks like and it may be than an example or two would help evaluators gain an idea what they are looking for.

Contrast section:

Checking with Firefox suggests the Juicy Studio Accessibility Toolbar. I would propose recommending the WCAG Contrast checker add on instead.

Rationale: They are both downloads, so both subject to the potential access restrictions that some might have. The Juicy Studio tool is less focussed as it includes functionality on ARIA, tables, etc, which may lead to more confusion. Most importantly, the WCAG Contrast checker tool provides a much better indication of failure and makes it significantly easier to identify what fails.

Branching from issue #1 – What do we need to address moving or animated content in Easy Checks?