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.

* <span style="background:yellow;">[EOWG please comment]</span> Background: [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013AprJun/0074.html Forms e-mail 10 June]. Given that easy checks can not tell you pass or fail for labels, and the liklihood of false failures, do we still want to include labels? See [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Criteria_for_checks Criteria for what to include].

* <span style="background:yellow;">[EOWG please comment]</span> Background: [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013AprJun/0074.html Forms e-mail 10 June]. Given that easy checks can not tell you pass or fail for labels, and the liklihood of false failures, do we still want to include labels? See [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Criteria_for_checks Criteria for what to include].

** comment <span style="color:#808080;">{name}</span>

** comment <span style="color:#808080;">{name}</span>

+

* <span style="background:yellow;">[EOWG please comment]</span> Is there a way to check label markup with FF toolbar? If not, should we not have a FF section at all?

* <span style="background:yellow;">[EOWG please comment]</span> Is there a way to check label markup with FF toolbar? If not, should we not have a FF section at all?

To Do

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

[EOWG thoughts?] In "what to do", visual focus:
"Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted. (A common problem is that the default focus indicator is turned off in CSS [@@ too jargony?] or elements are styled with borders that overlap or hide the focus indicator.)"

Public Comments

Jim Allan 6 June

Comment: Color/Contrast channeling Jared's <rant>!!! can we have an example of wretched grey text on a white background. Folks forget that grey and white are colors and may not think to check it.
[EOWG thoughts:

comment {name, date}

We could just change the first one to white background rather than adding another example. {Shawn, 6 June}

[closed?] Comment: zooming if you control+ in FF the images also get bigger. IE can change text size only (but with limits) main menu - view>text size in windows with wheel mouse, can zoom using control and mouse wheel (forward for larger, backward for smaller)
Resolution proposal: No changes. We have in the instructions for FF for text-only "From the menubar, select View > Zoom Text Only or, View > Zoom > Zoom Text Only". Jim must have missed that on quick read. For IE, we previously decided that it was too different across IE versions and also do not want to require mouse wheel for a check.
[EOWG thoughts:

previous wording was: "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted." ... maybe Jim just missed that in quick read?
Resolution proposal: Edited it to : "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, links have a gray outline around them or are highlighted."Is that good enough?

[closed pending EOWG OK] Comment: Page title: you mention checking with WAT toolbar in IE...need a link and what is WAT? Alt text (or anywhere in the page): need links to all mentioned toolbars Also, FF toolbar??? - which one - the one from UIUC, or Pendrick developers, or ??? +1 Wave is linked!!Resolution: Made the headings under "Using these Easy Checks" always visible and added "FF Toolbar and IE WAT " to "Tools"

[closed pending EOWG OK] Comment: in section: To practice checking alt text in BAD - what is BAD (I know, but newbies won't), make the link provided activeResolution: Made the headings under "Using these Easy Checks" always visible so "Practicing with BAD, the Before-After Demo" is visible. Also linked all BAD page URIs.

Other

Overall Comments

[in-progress] I agree with Tom's following thought: "Looking for an even simpler FIRST check, I've tried this one:FF Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images
With Alt Attributes; CSS -> Disable Styles -> Disable All Styles.
This is almost a visual "voice reader" simulation, except of course it
doesn't say "image," "link," and so on. But if the page looks good this
way (headings, organization, sensible alt text, etc.), it's probably
close. If it doesn't make sense this way, then more thorough analysis
is in order. (Try it on the inaccessible BAD Home page.)"{Sylvie}

[closed] Tom writes: "I understand why they've had
to include multiple systems (IE + FF), although FF can be used on any OS."Sylvie: It can be useful to evaluate with at least two browsers as they do not behave the same. For that reason, I think it is important to talk about IE and FF. {Sylvie}

Here is a draft to add at the end of the current page if the group thinks it is useful and not beyond the scope of an "Easy Check" {Sharron June 4}

Comments on Linearize

[EOWG comment]Do we want to include something like this at the end? What are the benefits? What are the cons? If we do, what comments do you have on the draft text? What should we call this section? (it's more than linearize, it turns off images & CSS as well)

comment {name, date}

comment {Sylvie, June 13} I am ok with draft 3 which simplifies draft 2 a bit. Nevertheless, I think the words "some people" are written too many times. I suggest following rewording in mixing drafts 2 and 3: While the other checks on this page focus on specific success criteria in WCAG 2.0, this check is more broad. It helps you understand how some people "see" the web page in other ways as usual. Frequently, web pages are designed with multiple columns and sections, colors, etc, that makes their content difficult to understand for users who are blind and listen to the page with a screen reader. Many users with low vision and others change the way the page is presented so they can read it; for example, change from multiple columns to one column, change the text size, and more. If you have no access to a screen reader or the knowledge of how to work with one, you may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles. This check gives you an idea of how people who are blind and others who get a linearized view experience the web page you are checking.Note: BAD provides a clear example of how the plain text view reveals accessibility barriers. (It's also a bit funny, and we suggest you check it out, per the BAD instructions below.)

I think this section could be helpful for people who need to have a quick look at a page without styles and images. this draft is not too long and clear. {Sylvie, June 6}

Linearize Page (Optional)

Not everyone has access to a screen reader or the knowledge of how to work with one. You may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles so that the reading order and text alternatives are exposed and can be evaluated.

What to do:

The checks below provide instructions with different browsers for how to:

Expose text alternatives by removing images

Reveal the reading order by turning off the associated style sheets

Examine the resulting page display for an approximation of a screen reader experience.

To linearize with IE WAT

Open the page you are checking in the IE browser

Using the toolbar, choose Images > Remove Images

Next choose CSS > Disable CSS

comment {name}

Shortcuts in WAT toolbar are: With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok".. {Sylvie, June 6}

To linearize with FF web developer toolbar

Open the page you are checking in the FF browser

Using the toolbar, choose Images > Disable Images

Next choose CSS > Disable Styles > Disable All Styles

comment {name}

In the French Web Developer version the keyboard shortcut to hide CSS is alt+shift+a, but I am not sure if it is the same in the English one. For disabling images, I only have the French version's shortcuts here. {Sylvie, June 6}

What to check for:

Read through the resulting display and notice the following:

Make sure that there is text in place of any meaningful images and that the text provides the same information as the original. (review alt text section above)

Verify that the reading order is logical, complete, and makes sense.

Comment: {Wayne Dick} The inclusion of the linearizatin is important to the easy checks. I liked Sharron's start, but it was not inclusive enough, nor did it motivate linerization sufficiently. Quite simply accessibility is not achievable without the ability to linearize content in a semantically faithful way. Sharron, I hope I expanded you piece to meet your approval

Linearize the Page for Experiential Learning (Optional)

When a page is converted form text to speech, to Braille, or to very
large print, the author's two dimensional presentation format breaks
down. Before a page can be converted to an appropriate medium it must be
reduced to a one dimensional information stream. This process is called
linearizing the page.

Not everyone has access to a screen reader, or powerful text
customization tools required to experience linearized content as it is
used, but a linearized presentation of content is easy to simulate using
the tools we have introduced so far. This can give the fully sighted
reader an understanding of the day to day experience of users with
blindness or low vision.

Linearization does not focus on any one success criterion, instead it
reveals how well a page is organized to support accessibility.
Example: Read the linearized view of the inaccessible version
in the BAD Demo. That will be fun, and it reveals a lot of what can go
wrong.

The checks below provide instructions with different browsers for how to:

Reveal the resulting page display for an approximation of a screen reader / customized text experience.

To linearize with IE WAT

Open the page you are checking in the IE browser

Using the toolbar, choose Images > Remove Images

Next choose CSS > Disable CSS

Shortcuts in WAT toolbar are:
With keyboard press ctrl+alt+shift+s to display the options dialog
box and uncheck the boxes "Images" and "CSS", then select "ok"..
{Sylvie, June 6}

To linearize with FF web developer toolbar

Open the page you are checking in the FF browser

Using the toolbar, choose Images > Disable Images

Next choose CSS > Disable Styles > Disable All Styles

In the French Web Developer version the keyboard shortcut to hide
CSS is alt+shift+a, but I am not sure if it is the same in the English
one. For disabling images, I only have the French version's shortcuts
here. {Sylvie, June 6}. This doesn't work in the English version {Wayne,
June 11}

What to check for:

Read through the resulting display and notice the following:

Make sure that there is text in place of any meaningful images
and that the text provides the same information as the original. (review
alt text section above)

Verify that the reading order is logical, complete, and makes sense.

<new> 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. </new>

tweaked wording a bit and added: This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminosity contrast".

7 March edit: moved the 3 options with pros & cons from under "To check contrast with IE WAT" up a level to apply to all.

Comments:

[closed] I think right above "Download the Color Contrast Analyzer" the heading needs to have the word "Windows" added so it changes to "To check contrast with any Windows browser." {Anna Belle}reply: a mac version is available - http://www.paciellogroup.com/node/18?q=node/20#macdownload{Andrew, 15/March}Questions: Is "you don't need to install it so should be able to do even in environments where you cannot install software." true for that TPG Windows & Mac versions as well? The current link goes to Vision Australia page with "Color Contrast Analyzer". The TPG version is called "Contrast Analyser" - which is better. Should we just point to that one? Reply: The CA and CCA are the same - when installed, the CA2.2a from TPG is actually 'Colour Contrast Analyser version 2.2a'. Also, the TPG and the Vision Australia downloads are the same tool - it was originally developed at Vision Australia then Steve moved it to TPG when he moved - VA retain up-to-dates version on their site. I don't know if the Mac version needs to be 'installed' or not. {Andrew, 22/March}[open action for Mac] Someone please check if "you don't need to install it so should be able to do even in environments where you cannot install software." is true for that TPG Windows & Mac versions?I tried on a Mac and the link on the page (unlike Andrew's link) sends me to a download page that's for Windows not Mac. That's even when I'm on a Mac. Maybe have a second link for Mac?{Anna Belle. May 30}The Windows one required me to be admin as well, so I just deleted this all together. {Shawn}

Zoom

7 March edits were mostly minor. Note new second sentence in first paragraph: "Some need to change other aspects of text display: font, space between lines, and more." This is important so that readers don't think simple zoom covers all user needs (like in the color section we mention the need for low luminosity).

Comments before 10 June

[closed? added to current draft intro sentence with all issues] The prose version is a significant improvement over the bullet version. The former leads off with a clear introductory sentence and then proceeds with a nice overview of the issues, providing a rationale for the more detailed instructions that follow. The bullet version starts right off with specifics which is jarring and disorientating. {Howard, 6 June}

Other observations/feedback: {Howard, 6 June}

[done. fixed] the link to the "preliminary" page is broken

[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

Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? {Shawn 10 June}

[closed. current draft has "Find forms on the page."] "Find Forms" header under "What to do" seems too open. Suggest: "Find the forms on the page" (too wordy?); or "Find form elements" (too technical?)

I agree. I like first suggestion and would add to this that we move "If there are forms on the page ...." sentence to below the bullet points and right above what it refers to. {Anna Belle, 8 June}

[closed? current draft has bullets under the subheads] This section, being lengthier than the others, calls for additional indentation - under the brown headers, such as "What to do", "What to check for", etc. Too much lines up along one left margin. Some additional indentation would add readability. (Perhaps once images are added, this will help subdivide the section)

[closed current draft covers it in keyboard section] Maybe the "submit button" section could be replaced with a statement such as: "Form data should not be submitted without user confirmation" (followed by more detailed instructions?)

[closed? edited in current draft] I think error messages should be addressed in "to learn more about forms." Otherwise, this section is getting to lengthy and thus no longer an "easy check".

@@As mentioned under "to do items," the group label is not sufficiently explained. Maybe have a link from "group label" where it can be further explained.

As discussed in EOWG's 31 May teleconference, I suggest changing the checks order as proposed below:

Labels

Instructions

Keyboard access and reading order

Submit buttons

Data input and error messages

{Sylvie June 4, 2013}

In section "error messages", we should give clear instructions on what to look for, avoiding asking for judgement.

Check that there is guidance to help user understand and fix the error.

The focus moves to the error message

Error information is not located at the end of the form, but rather at the beginning.

The user is not requested to fill in the whole form again, but only the error fields.

If the error concerns a format, such as date, time, address, suggestions are made to enter the correct format.

If a required field has been forgotten, that this field is indicated with colour and text such as "mandatory" or *.

{Sylvie June 4, 2013}

[EOWG discuss]Are these easy checks? I wonder if all of what's currently in the Forms section qualifies as easy checks? For example, - Is "Instructions" too soft/unclear/nonspecific? - Indicating required fields is a bit tricky. Do we say enough here? Or is it too complex for an easy check? ... oh, I see now that required is in the Instructions subsection and the Labels section. - Is "Data input and error messages" too hard for an easy check? Also: My preference would be *not to have any specific instructions* under "2. Keyboard access and reading order" but instead have just a point to the keyboard access section above (and make sure it clearly includes keyboard access issues for forms). If y'all disagree, we can talk about that in EOWG telecon. Also: "4. Submit buttons" is already covered in the keyboard access section above. I don't think we want to repeat it. (also, most of these wouldn't have buttons labeled "submit", they'd be something like "go to Page") Perhaps we want to re-focus this section to just Form Labels?{shawn}

Reconsider the "What to do" section. Remember we've positioned this Easy Checks as applying to ONE web page (so "Check through the web pages to look for examples of forms." is not relevant). Can you make that section more succinct? Do we even need it at all? (Maybe to point out that a search box is a form?) {Shawn}

BAD: Rather than having a link to BAD in the "To learn more about forms" section without any explanation of what to look for in BAD, perhaps it would be useful to have a section on using BAD to check forms issues -- for example, like this one for alt: <http://www.w3.org/WAI/EO/Drafts/eval/checks#bad-alt> ? {shawn}

[closed] Suggest changing:Forms are used for interacting with websites and are common across the Web. They are used for activities such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. to: Forms are used for SUBMITTING DATA TO websites and are common across the Web. They are used for OPERATIONS such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. {Howard 23 May}Suggest changing: Forms are made up of controls such as text entry fields, check boxes, radio buttons, drop-down boxes and finish with submit buttons. to: Forms CONSIST of data entry fields, including text fields, check boxes, radio buttons, drop-down boxes and controls, usually consisting of a submit button. {Howard 23 May}Actually, I think the introduction should take a different approach — not to introduce forms per se, but to introduce some of the accessibility issues with forms — like the other sections do. {Shawn 24 May}

[closed] Suggest changing: For longer or unusual forms, check for instructions. to For long or complex forms, check for instructions.

Suggest deleting: Instructions are usually needed to explain how to fill out the form.{Vicki 24 May}

[closed] Suggest changing: Are there instructions at appropriate places in the form (usually at the beginning and the start of discrete sections) that clearly explain how to fill out the form? to Are the instructions positioned appropriately (usually at the beginning of the form and/or at the start of specific sections)? Do the instructions clearly explain how to fill out the form?

Suggest changing: Are required fields explained in the instructions and clearly identified throughout the form? to Are the required (mandatory) fields explained in the instructions and clearly identified? {Vicki 24 May}

SK/MC case study - Good to have forms, but new post form was not available for public view. Really need to have a developers toolbar or IE WAT or WAVE to test this easily. Developer could not access tools from his machine and I could not access the page from my machine! We looked at BAD in order to consider the principles, having an example really helps. {Suzette}

[done] suggest changing "Most video on the web that provides captions has "closed captions" that need to be turned on." to: "Most video on the web that provides captions has "closed captions" that can be turned on and off". {Howard - May 31}

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}

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}

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

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

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}

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}