Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Easy Checks

From Education & Outreach
Revision as of 12:19, 28 June 2013 by Andrew (Talk | contribs)

Jump to: navigation, search

Nav: EOWG wiki main page > Evaluation Pages
[Old Web Accessibility Preliminary Evaluation page]

Easy Checks - A First Look at Web Accessibility

Related pages:

To Do

Page titles

  • [OPEN action] Find a keyboard way to display the full page title in IE 9 and later and chrome.
  • Chrome and some versions of IE do not have a title bar. In those browsers you can see the full page title by hovering over the tab [@@keyboard way to do this?], like this: [@@ need to redo this image with a browser that does not have a title bar]


  • [EOWG comment] Learn more about headings - Delete the techniques? Elsewhere we just have links understanding success criteria. Would it be too much -- and beyond Easy Checks goal -- to list all the relevant techniques for each section?


Keyboard access and visual focus

  • [EOWG thoughts?] Is it specific and clear enough to write: "To select a specific item within an element such as a drop-down list, press the Enter key or Space bar."

Multimedia (video, audio) alternatives

  • [OPEN action] In Section "captions", look for a way to turn on open captions with the keyboard, for example in Youtube activating the CC button. (How to do it with nvda from Howard.)- Did some more checking with NVDA & YouTube - see my updated comments at this url - Howard
  • [EOWG thoughts?] "If there are captions, transcripts are not usually required; however providing transcripts in addition to captions has many benefits — both to people with disabilities and to website owners. [EOWG: OK to say??]" Should we point to Benefits?
  • [EOWG thoughts?] "Check that transcripts include all audio information, including dialogue with the speakers identified, and all important sound [repeat examples above or not?]."

Forms and errors

(Other open issues are being discussed in the Forms section below.)

  • [EOWG thoughts] In BAD, it seems that the focus does not go to the error messages. Shall we still include BAD for checking errors? We can submit a change request for BAD, but it will likely be a while before it gets implemented.
  • [OPEN action] suggest edit for: "Data tables will not make sense when linearized -- that's OK -- screen readers have functionality to make them usable (when the table is marked up correctly)."
  • [EOWG thoughts] suggest edit for: "Check that the information makes sense, for example, [@@ reading order]."

Plain text view / Linearize

  • [EOWG thoughts] [ Make sure that there are reasonable ways to skip around long lists of links and other boiler plate content that is repeated on every page in the site. @@ need to be more specific on this one - how do they check that? what specifically are they looking for? or is this not a priority and we should leave it out?]
  • [EOWG thoughts] To practice checking plain text view with BAD section: Do we want to point out other things?

Next Steps


  • [wait until illustration strategy is decided] Check img alts - some might have @@
  • [wait until illustration strategy is decided] Decide if we want more images for the steps. Search for [image].
  • [done for now] Search for other open things in [brackets].
  • Search throughout for the perspective that the content needs to work, rather than the user has a limitation. e.g., 'users need to be able to' vs. 'websites need to enable users to' {Shawn}




  • Illustrations of focus indication would be useful. Shall I send screen shots to the list or how to provide? {Sharron}
    Send them to Shawn & she'll upload them :) {Shawn}

Forms, form labels, and error messages

Forms in WAI draft page

Comments after 14 June

  • comment {name}

Downloaded new version of WAT - it is clearer that something is wrong than in previous version - many things are labelled now as input errors and also select errors and container errors - which Easychecks don't mention. Some specific fields picked up as lacking 'label for'. Is there a simple explanation for input and select errors? WAVE was easier to understand with its red and green luggage labels but there is a lot of other issues identified too. FF has a feature on Forms/ outline form fields without labels - the outline is a bit too subtle and easy to miss! On the other hand, if the form passed most success criteria I guess the whole thing would be much simpler! Is it sufficient that the novice tester can just say that this form needs further investigation?)

  • [EOWG review] "Check that the focus is at the error message."
    Proposal for clearer guidance:
    After you have submitted the form with errors, check that your browser brings you directly to the first error on the page. One best practice is to list all errors at the beginning of the form that contain an internal link leading directly to each error."{Sylvie, 17 June}
    • Two questions with this:
  1. How do people "Check that the focus is at the error message" or "check that your browser brings you directly to the first error on the page"? I think this is easy to check with a screen reader but maybe not visually?
    Response from Sylvie on June 18: if you take the example of search engines like Google, when you open the home page your browser prompts you directly to the search field, and this even without a screen reader. I am right?
    Response from Shawn on 25 June: Yes, but how can the the person doing the check check that? Visually, if it is a text box, there is a cursor. How check non-visually? What if it's a control other than a text box? Or just a plain text message? How check that the focus is there?
  2. The next bullet says: "Generally it is best if the error messages are before the form, rather than after the form." Is saying "One best practice is to list all errors at the beginning of the form that contain an internal link leading directly to each error." too prescriptive? If not, how can we integrate it into the existing bullet?
    {Shawn, 17 June}
    I am not sure if it is too prescriptive. It is only an example of what can be done to help the users find the errors. {Sylvie, 18 June}
  • [EOWG review] In the note for labels checks, clarify following sentence:
    "Note: These instructions help you check if labels are marked up with 'label', 'for', and 'id'; they do not check if form controls are identified in other ways. Therefore, even if a form does not pass these checks, it might still meet WCAG 2.0 another way."
    {Sylvie, 14 June}
    • I added the sentence before in your blockquote. Can you say what is not clear? How me might clarify it? {Shawn, 17 June}
    • I mean the sentence: "Therefore, even if a form does not pass these checks, it might still meet WCAG 2.0 another way." I am not sure that this "another way" is clear. {Sylvie, 18 June}
    • [EOWG]: Do we want to be more specific? Or how else can we be clear without being too techy and detailed?
    • Would it be any clearer if "be WCAG another way" were changed to "meet WCAG in another way"? {Bim, 28 June}
  • [closed ?] In Check labels with FF, I don't understand following note:
    (There's not an easy way to check form control labels with the FF toolbar. The Form Labels favelet works with Firefox, yet it requires installation.)
    What does this enable you to do? Why do you mention that it requires installation, as FF toolbar also requires installation. More explanations are needed here. {Sylvie, 14 June}
    • OK, I added more explanation: "The Form Labels favelet works with Firefox and provides the same information as from IE WAT above." We mention it requires installation because in the beginning we say we only use to 2 tools that require installation, so this is an exception. {Shawn, 17 June}

Closed comments:

  • [done. changed to drop-down lists] I thought we talked in one eowg conference about the term "drop-down list box". Is it really the right term or don't you call them drop-down lists? {Sylvie, 17 June}
    • "drop-down list box" seems clearest. Is that OK? {Shawn, 17 June}
    • I never heard that before but if it is the current term, it is ok. {Sylvie, 18 June}
  • [closed.] I am not sure if it is linked to my screen reader, but I am not able to have the links work, such as the link to drop-down list box. {Sylvie, 17 June}
    That's because the in-page links go to other sections that are now in the main document at /WAI/eval/ but not in this draft (at /WAI/EO/Drafts...) anymore. They should work when we move this section into the main document.
  • [fixed.] In the paragraph "Error handling", first sentence, there seem to be a typo:"Some single simple forms, such as a single search fields,"write "a single search field". {Sylvie, 17 June}

Earlier comments still open 18 June

  • [EOWG open - heading for this section simply "Forms?" or more?]
    Title on current version is "Forms and Error Messages" but in this wiki it's "Forms, Form Labels, and Error Messages." I prefer the latter {Howard, 6 June}
    • Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? {Shawn 10 June}


  • comment {name, date}

[EOWG open]What to call this section?

(Keep in mind how it fits with the other items in the contents list.)


  • Plain Text View
  • Linearize the Page for Experiential Learning
  • Basic Display
  • Bare Bones Display
  • How some people "see" the web page
  • Information Organization
  • Different Presentation
  • ...


  • I think plain text is a misleading term. It makes me think of the <pre> element. Very fixed and very rigid. Linearized text, is marked up HTML. There are links, headings, paragraphs everything but style, and regrettably data tables. Actually it is styled with the default HTML style. Links are blue, headings are big and lists are lists.
    Linearizatized text is very structured markup in a different format. If linearize is to geeky how about "reading order" --convert the page to reading order.
    For me plain text has a very bad connotation. People used to give ASCII page equivalents that were rarely equivalent. These alternatives were referred to as "plain text" alternatives.
    {Wayne, 17 June}
  • It's more than linearize or reading order, it turns off images & CSS as well. {Shawn}
  • I think "Linearize" has a foundation that can be explained and is traditional. But it could also be something like, "undress the page", or "stripping the page".{Emmanuelle, 18 June}
  • I agree with Wayne about the bad roof of plain text. I am afraid people think that making a page accessible is providing a text version without images and anythhing else. I like Emmanuelle's "undress the page" (I mean the idea in it). From the proposals above I would prefer "different view", or what about "alternate view or presentation?"? {Sylvie, 20 June}
  • I find the current draft of this section somewhat confusing - sometimes "linearize" is used, sometime "plain text". The difference between the 2 are not clear, at least not spelled out. I found the diagrams confusing because there's no explanation of how you render in 1 column versus "page linearized with styles off." I'm a little concerned with the term linearized - it's not a term, I believe, that is used in any other tool such as Wave or Web Dev'l Toolbar, etc. Perhaps there should be only one example (since this is easy checks) - a page with styles turned off. Explain this is used to hear how a screenreader will render the page. {Howard, 27 June}
  • How about "Text view" or "Reading order"? {Bim, 28 June}
  • Among the suggestions above, I prefer:
    • How some people "see" the web page
    • Information Organization
    • Or Bim's suggested "reading order".
    {Sylvie, 28 June}
  • I also like the idea behind "undress the page". What about "simplify the page" or "basics of the page" or "See the page framework" or similar {Andrew, 28 June}
  • comment {name, date}

Next Steps

  • comment {name, date}


Thanks to:

  • Those who participated in the F2F before CSUN in February: Andrew, Anna Belle, Helle, Jennifer, Shadi, Sharron, Shawn, Wayne
  • Those who edited in December and January: Suzette (forms, @@), Sharron (Intro, @@), Shawn (Intro, page titles, headings, alt text), Ian (zoom n text resize).
  • Those who commented in December and January: Sylvie, Wayne, Anna Belle, ...
  • Those who drafted checks 16-28 November:
    • Sharron for drafting {list sections!}
    • Suzette for drafting : Check usable with page zoomed and text enlarged, Check color contrast, Check color coding and shape coding, {?other sections}
    • Wayne for drafting {list sections!}
  • Andrew & Shawn for editing the keyboard access & visual focus section in early Nov.
  • Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the f2f in Nov.
  • Sharron for help making all the early drafts and versions less confusing.
  • Wayne and Ian for sharing colleagues' related work.
  • Denis for edits to the old page content.

testing image: search-icon.png

Internal Notes



  • To see all illustrations, make sure to "expand all sections" because some of the illustrations are in collapsed sections. (however, keep in mind that most of the images will be collapsed by default)
  • Make sure to evaluate the images in context, that is, read the text around it and imagine you are a user.

Questions: How is the current use of images for illustrations throughout the draft? Too much? Not enough? Mostly helpful? Too cluttering? Feel free to comment in general, and on specific images.

  • comment {name}
  • From 24 May teleconference:
    • Generally the conceptual images are useful for contrast and zoom; simply the page title images {done 24 May}.
    • Mixed perspectives on the images showing menu items and such. For some people they are just clutter, the word instructions are clear enough. For other people, the images really help.
    • For now:
      • Include images showing menu items and such judiciously — if in doubt, do not include an image.
      • Crop or gray out all unnecessary clutter in images. (for example, page-title-image has the content of the web page grayed out.)


I'd like to discuss strategy for illustrations. {Anna Belle, June 9} Here are questions to consider:

  • Do we want to use captions? Always? Sometimes? If sometimes, then what distinguishes when they are needed?
    • I think it is visually simplier without captions. The images are all illustrations of specific points and the images are right after the points, then I don't think they need captions. {Shawn, 12 June} Agree {Andrew, 13 June}
  • If we use captions, then how? E.g. do we give a 10 pixel padding with a border that encloses both image and captions?
  • Do we have images embedded in the text flow or do we separate them out (e.g. float to right)?
    • I suggest embedded in the text flow. {Shawn, 12 June} Agree {Andrew, 13 June}
  • In some images do we want to use embedded explanatory text and arrows? This may be necessary if we aren't using captions. And even if we do use captions, for some concepts it may illustrate the point more clearly.
    • I suggest keep them simple -- both for the users reading the page and for us developing the images. I think it would be best to crop and gray out an irrelevant information in the images, and not have to use arrows. Also, if the images are embedded and they are illustrating the text right above them, then they shouldn't need explanatory text. {Shawn, 12 June}
  • What is the maximum width for an image?
    • We previously decided to make most images 700px wide. We can revisit that decision. {Shawn, 12 June}
  • If width is narrow (e.g. 350 pixels), some images will need to be shrunk to a size where detail may be lost. Is that okay? Or do we want to offer a link to a larger version of the image in such cases?
    • I vote let's try to make the images useable in the page, and not add the complexity of linking to a larger image. {Shawn, 12 June}
  • Do we want to number illustrations? Thus in the text we could say, "See Figure 3" multiple times if Figure 3 is relevant multiple times.
    • If we were referring to a single image multiple times, then we would need to do something like this. However, I think we don't refer to an image more than once. Also, currently the images are embedded in the text right after what they illustrate. Therefore, I think it would add unnecessary complexity (both for users and for us ;-) to number the illustrations. {Shawn, 12 June} Agree {Andrew, 13 June}
  • Do we want to incorporate all illustrations into the expand sections button? Or perhaps have a separate "See illustrations" button? (I dislike both of these ideas, by the way.)
    • Currently there are 3 types of images:
      1. Illustrate the concept (e.g., page titles, contrast, zoom).
      2. Illustrate the toolbar things to click.
      3. Illustrate the results from the tool, e.g., alt text next to images.
      Currently the concept images (1) are always shown, and the toolbar images (2 & 3) are shown only when that specific checks step is expanded. I think this works well. [Agree {Andrew, 13 June}]
      For the checks steps, we could have the illustrations not visible by default and a button to show illustrations. That might be best for usability; however, I don't think it's a high enough priority for our time. We do not currently have such functionality developed so it would be a new thing to do. {Shawn, 12 June} [Agree - and we don't need more delays in releasing {Andrew, 13 June}]
      To see how it might work, I put Images illustrating linearized and changed display (click to show images)
  • Do we want to limit illustrations to one per concept? If the concept is tricky to illustrate (e.g. how to see titles) do we want to offer the option of clicking through to more illustrations?
    • I don't think we want the complexity (for the users or for us) of adding the option to get more illusrations on a different page. Right now we have the following concept images:
      • Page titles - 1. shows page title in title bar and cut off in tabs. 2. shows how to get the title from the tab when there is not a title bar. [@@ we need to redo this image with a browser that does not have a title bar :-]
      • Contrast - several images that show different color combinations that are mentioned in the text.
      • Zoom - 2 that show a page not zoomed and zoomed.
      I don't think it makes sense to put these one a separate page. {Shawn, 12 June}
  • Do we want to standardize the format to the image? JPG? SVG? PNG?
    • I think png {Shawn, 12 June}
  • Would it be helpful to specifically state the goal for each illustration in the wiki? E.g. with titles, is it to show people how to see the title at the top of a browser (whether embedded in a tab or not)?
    • Yes. Please do! ;-) {Shawn, 12 June}
  • What should be the alt (&/or title) for illustrations in different cases, e.g., if the images are sufficiently described in the text, then null? {Shawn, 12 June}
    • For the Page Title images: Let me change the suggestion to indicating this information with a title attribute - the images look different from what I see on my setup, so hovering would show what browser & version was being illustrated {Andrew, 15/March}

Recommendations for Illustrations:

Andrew and Anna Belle, 6/27/13

Phase I

  1. Visually separate illustrations from the text flow by putting border and 10 pixel padding around them.
  2. Do not float illustrations. Width issues and where they fall relative to the text are too complicated.
  3. Use captions as a general rule. Illustrations including captions within a border are visually simpler because the reason for their inclusion is explained rather than having to be deduced.
  4. Gray out irrelevant information in the images, and avoid using arrows if possible.
  5. The maximum width is 600 pixels.
  6. Illustrations will not centered, not right/left justified.
  7. Use PNG for the format.
  8. Specifically state the goal for each illustration in the wiki. This will help select the best illustration.
  9. Alt text should (1) briefly explain what is being illustrated and (2) reflect the browser (including the version) and operating system used for browser illustrations.
  10. Aside: We might consider embedding illustrations in a div element with a class of "figure" in preparation for HTML5. If we do this then the captions can go in a span with a class of "figcaption."

Phase II

  1. Convert to HTML5 so we can use <figure> and <figcaption> elements for illustrations.
  2. Add a widget to toggle illustrations on and off.

Illustration Goals

Plain text view:

  • Visually illustrate the concept of linearize
  • Simple example of how a layout can linearize in different order
  • Show what they can expect when they follow the steps
  • Show how people with low vision might change the display, to help show it's not just screen readers

Case study notes

See SK/MC Case Study Notes in the 30 May 2013 snapshot

Consider for Later

  • The text says: "The first thing screen readers say when the user goes to a different web page is the page title. Page titles are important for orientation — to help users know where they are and move between open pages."
    Would it be useful to have a sound clip of the screen reader going through page titles? Low priority, but maybe neat for people who don't know screen readers? {Shawn}

previous versions, etc.