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.

# 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?<br /><span style="color:#808080;">Response from Sylvie on June 18:</span> 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? <br /><span style="color:#808080;">Response from Shawn on 25 June:</span> 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?

# 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?<br /><span style="color:#808080;">Response from Sylvie on June 18:</span> 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? <br /><span style="color:#808080;">Response from Shawn on 25 June:</span> 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?

−

# 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?<br /><span style="color:#808080;">{Shawn, 17 June}</span><br />

+

# 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?<br /><span style="color:#808080;">{Shawn, 17 June}</span><br />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. <span style="color:#808080;">{Sylvie, 18 June}</span>

−

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. <span style="color:#808080;">{Sylvie, 18 June}</span>

+

* In the note for labels checks, clarify following sentence: <br /><blockquote>"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."</blockquote> <span style="color:#808080;">{Sylvie, 14 June}</span>

* In the note for labels checks, clarify following sentence: <br /><blockquote>"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."</blockquote> <span style="color:#808080;">{Sylvie, 14 June}</span>

**I added the sentence before in your blockquote. Can you say what is not clear? How me might clarify it? <span style="color:#808080;">{Shawn, 17 June}</span>

**I added the sentence before in your blockquote. Can you say what is not clear? How me might clarify it? <span style="color:#808080;">{Shawn, 17 June}</span>

To Do

[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?

[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.)

[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?]."

[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] [ 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?]

Forms, form labels, and error messages

Comments after 14 June

[EOWG open comments below]

comment {name}

[EOWG comment] "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:

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?

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}

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}

[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}

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}

comment {name, date}

Next Steps

comment {name, date}

Contributors

Thanks to:

Those who participated in the F2F before CSUN in February: Andrew, Anna Belle, Helle, Jennifer, Shadi, Sharron, Shawn, Wayne

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.)

Strategy:

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)?

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}

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

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}