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.


Difference between revisions of "Web Accessibility Preliminary Evaluation"

From Education & Outreach
Jump to: navigation, search
(Image text alternatives ("alt text"))
(Headings)
Line 137: Line 137:
  
 
==Headings==
 
==Headings==
<span style="color:#808080;">''[updated 8 Feb]''</span>
+
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#headings Headings in WAI draft page]'''
 
+
Web pages often have sections of information separated by visual headings, for example, heading text is bigger and bold (like "Check headings" right above this sentence :-). To make these work for all users, the headings need to be "marked up" in the web page "code" (e.g., HTML). That way people can navigate to the headings &mdash; including people who cannot use a mouse and use only the keyboard, and people who use a screen reader.
+
 
+
Heading levels should have a meaningful hierarchy, e.g.:
+
<ul>
+
  <li>Heading Level 1 &lt;h1&gt;
+
      <ul>
+
        <li>Heading Level 2 &lt;h2&gt;
+
            <ul>
+
              <li>Heading Level 3 &lt;h3&gt;</li>
+
              <li>Heading Level 3 &lt;h3&gt;</li>
+
            </ul>
+
        </li>
+
        <li>Heading Level 2 &lt;h2&gt;
+
            <ul>
+
              <li>Heading Level 3 &lt;h3&gt;
+
                  <ul>
+
                    <li>Heading Level 4 &lt;h4&gt;</li>
+
                    <li>Heading Level 4 &lt;h4&gt;</li>
+
                  </ul>
+
              </li>
+
            </ul>
+
        </li>
+
        <li>Heading Level 2 &lt;h2&gt; </li>
+
      </ul>
+
  </li>
+
</ul>
+
 
+
 
+
<strong>What to check for:</strong>
+
      <ul>
+
        <li>Are there headings marked up?</li>
+
        <li>Is the hierarchy meaningful? (Ideally the page starts with an "h1" &mdash; which is usually similar to the page title &mdash; and does not skip levels; however, this is not an absolute requirement.)</li>
+
        <li>Is there text that looks like headings but is not marked up as a heading?</li>
+
        <li>Is there text that is marked up as headings that is not really a section heading?</li>
+
      </ul>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To check headings outline <em>- with IE WAT:</em></strong>===
+
<ol>
+
<li>Open the web page you are checking.</li>
+
<li>In the toolbar, select "Structure", then "Heading Structure". Or, with the keyboard: [@@keyboard shortcut]<br />
+
''A new page opens with the outline.''</li>
+
<li>Non-visual checks:
+
      <ul>
+
        <li>Are headings listed. If there are no headings marked up, it will say "0 headings".</li>
+
        <li>Does the outline start with [H1] and follow a meaningful hierarchy? (That's not required, but strongly suggested.)</li>
+
      </ul>
+
  </li>
+
  <li>Visual checks: Compare the Document Outline to the visual rendering of the page.
+
      <ul>
+
        <li>Are the things that look like headings on the page listed in the Document Outline?</li>
+
        <li>Are there things in the Document Outline that aren't really headings? </li>
+
      </ul>
+
  </li>
+
</ol>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To check headings outline <em>- with FF toolbar:</em></strong>===
+
<ol>
+
<li>Open the web page you are checking.</li>
+
<li>In the toolbar, select "Information", then "View Document Outline". <span style="color:#808080;">[image]</span> Or, with the keyboard: [@@keyboard shortcut]<br />
+
''A new page opens with the outline''</li>
+
<li>Non-visual checks:
+
      <ul>
+
        <li>Are headings listed. If there are no headings marked up, it will say "0 headings".</li>
+
        <li>Does the outline start with [H1] and follow a meaningful hierarchy? (That's not required, but strongly suggested.)</li>
+
      </ul>
+
  </li>
+
  <li>Visual checks: Compare the Document Outline to the visual rendering of the page.
+
      <ul>
+
        <li>Are the things that look like headings on the page listed in the Document Outline?</li>
+
        <li>Are there things in the Document Outline that aren't really headings? </li>
+
      </ul>
+
  </li>
+
</ol>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To check headings outline <em>- in any browser</em>:</strong>===
+
<ol>
+
  <li>In any browser, open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li>
+
  <li>In the Address field, type the URI (e.g., www.w3.org).</li>
+
  <li>Click the More Options link.</li>
+
  <li>Select the Outline checkbox.</li>
+
  <li>Click the Check button.
+
<br />''The results page appears (with title starting either [Valid] or [Invalid]).''</li>
+
  <li>In the results page, near the top, at the end of the "Jump to:" line, click the Outline text link.</li>
+
  <li>Non-visual checks:
+
      <ul>
+
        <li>Is there anything there? If there is no text between "Below is an outline for this document, automatically generated from the heading tags (&lt;h1&gt; through &lt;h6&gt;.)" and "If this does not look like a real outline..." it means there are no headings marked up on the page.</li>
+
        <li>Does the outline start with [H1] and follow a meaningful hierarchy? (That's not required, but strongly suggested.)</li>
+
      </ul>
+
  </li>
+
  <li>Visual checks: Compare the Document Outline to the visual rendering of the page.
+
      <ul>
+
        <li>Are the things that look like headings on the page listed in the Document Outline?</li>
+
        <li>Are there things in the Document Outline that aren't really headings? </li>
+
      </ul>
+
  </li>
+
</ol>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To show heading markup in the page <em>- with IE WAT:</em></strong>===
+
<ol>
+
<li>Open the web page you are checking.</li>
+
<li>In the toolbar, select "Structure", then "Headings". Or, with the keyboard: [@@keyboard shortcut]<br />
+
''Headings will be surrounded with &lt;h1&gt;, &lt;h2&gt;, etc. icons in purple text on tan background.''</li><span style="color:#808080;">@@perhaps avoid indicating colors.  This can change with updates and it's hard to keep track of.  The indication of &lt;h1&gt; will certainly remain in future versions.</span>
+
  <li>Anything that is a functional heading should have a heading icon before it.</li>
+
  <li>Anything that is a '''not''' functional heading should '''not''' have a heading icon before it.</li>
+
</ol>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To show heading markup in the page <em>- with FF toolbar:</em></strong>===
+
<ol>
+
<li>Open the web page you are checking.</li>
+
<li>In the toolbar, select "Outline", then "Show Element Tags Names When Outlining". Or, with the keyboard: [@@keyboard shortcut]<br /></li>
+
<li>In the toolbar, select "Outline", then "Outline Headings". Or, with the keyboard: [@@keyboard shortcut]<br />
+
''The headings will be outlined and &lt;h1&gt;, &lt;h2&gt;, etc. icons will be before the headings.''</li>
+
  <li>Anything that is a functional heading should have a heading icon before it.</li>
+
  <li>Anything that is a '''not''' functional heading should '''not''' have a heading icon before it.</li>
+
</ol>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To show heading markup in the page <em>- with any browser:</em></strong>===
+
<ol>
+
  <li>Open [http://wave.webaim.org/ WAVE] web accessibility evaluation tool.</li>
+
  <li>Type the website address in the box after &quot;Enter the URL of the web site you want to evaluate:&quot;</li>
+
  <li>Click the &quot;WAVE this page!&quot; button.<br />
+
''Your web page will show up in the browser with lots of little icons on it.''</li>
+
  <li>Anything that is a functional heading should have a heading icon (<span style="color:#808080;">[image]</span>, <span style="color:#808080;">[image]</span>, ...) before it.</li>
+
  <li>Anything that is a '''not''' functional heading should '''not''' have a heading icon before it.</li>
+
</ol>
+
 
+
===<span style="color:#808080;">[+/-]</span> <strong>To try checking headings in BAD:</strong>===
+
 
+
To check headings outline: <em>[non-visual]</em>
+
<ul>
+
<li>Follow the one of the instructions under "To check headings outline" above and use the accessible News page: <code>www.w3.org/WAI/demos/bad/after/news</code>. Notice there is a nice hierarchical outline.</li>
+
<li>Next, use the inaccessible News page: <code>www.w3.org/WAI/demos/bad/before/news</code>. (In HTML Validator, the "Check" button might now say "Revalidate".) Notice there is just one heading.</li>
+
</ul>
+
 
+
To show heading markup in the page: <em>[visual]</em>
+
 
+
<ul>
+
 
+
<li>Start by visually looking at the [http://www.w3.org/WAI/demos/bad/before/news.html BAD news page]. What looks like headings? ''(Citylights News, Heat wave linked to temperatures, Man Gets Nine Months in Violin Case, ...)''</li>
+
 
+
<li>Next, see how it should look. Follow one of the instructions for "To show heading markup in the page" above on the accessible News page: <code>www.w3.org/WAI/demos/bad/after/home</code>. Notice the headings have icons next to them.</li>
+
 
+
<li>Next, see what it looks like when headings are not marked up. Use the inaccessible News page: <code>www.w3.org/WAI/demos/bad/before/home</code>. Notice there is text that visually looks like headings, but does not have headings icons next to it. (With WAVE, there are yellow icons with "h?" because it thinks these might be headings.)</li>
+
</ul>
+
 
+
===<strong>Learn more about headings from:</strong>===
+
<ul>
+
 
+
<li>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html Info and Relationships] - Understanding Success Criteria 1.3.1 for WCAG 2.0 (Level A)</li>
+
 
+
<li>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html Headings and Labels] - Understanding Success Criteria 2.4.6 for WCAG 2.0 (Level AA)</li>
+
 
+
<li>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-headings.html Section Headings] - Understanding Success Criteria 2.4.10 for WCAG 2.0 (Level AAA)</li>
+
 
+
<li>Techniques for WCAG 2.0:
+
<ul>
+
<li>[http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G130 G130: Providing descriptive headings]</li>
+
<li>[http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141: Organizing a page using headings]</li>
+
<li>[http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42.html H42: Using h1-h6 to identify headings]</li>
+
<li>[http://www.w3.org/TR/WCAG20-TECHS/H69.html H69: Providing heading elements at the beginning of each section of content]</li>
+
<li>[http://www.w3.org/TR/WCAG20-TECHS/F2.html F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text]</li>
+
<li>[http://www.w3.org/TR/WCAG20-TECHS/F43.html F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content]</li>
+
</ul>
+
</li>
+
 
+
<li><span style="color:#808080;">[@@Do we want to point to a resources that shows how screen reader users navigate with headings? There's not much detail in [http://www.w3.org/WAI/intro/people-use-web/principles accessibility principles] ... ]</span></li>
+
</ul>
+
 
+
<br />
+
<hr />
+
  
 
===<span style="color:#808080;">EOWG Notes on Headings</span>===
 
===<span style="color:#808080;">EOWG Notes on Headings</span>===
  
* <span style="color:#808080;">comment {name}</span>
+
<div style="color:#808080;">
 +
* comment {name}
  
<span style="color:#808080;">low priority:</span>
+
</div>
<ul>
+
<li style="color:#808080;">do we want to find an appropriate example of text that is marked up as a heading but it not really a heading?</li>
+
* <span style="color:#808080;">Here is one from University of Washington's [http://www.washington.edu/accesscomputing/AU/before.html Accessible University 2.0], fictional pages to teach web accessibility. The Security Check is the only thing marked as a heading. Not sure it fits what we need, and will keep looking. {Sharron}</span>
+
OK, here's a sample, can do in HTML if we have anyplace to put it...[http://www.w3.org/WAI/EO/wiki/Headings_what_not_to_do What not to do for Headings]
+
<li style="color:#808080;">do we want to find an appropriate example of a web page with no headings at all? to show what you get in the Validator outline?</li>
+
</ul>
+
  
 
<hr />
 
<hr />

Revision as of 00:33, 9 February 2013

Nav: EOWG wiki main page > Evaluation Pages
Old page on WAI website: Prelim Eval

Notes


Important Note: For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way — for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.

Easy Checks - A First Look at Web Accessibility

title ideas

Contents

[Thanks to #Contributors!]

Introduction

[Updated 8 February]

These easy checks guide non-experts to gauge the accessibility temperature of a web page. With these few simple steps, you can get an idea whether or not accessibility is addressed in even the most basic way.

These checks cover just a few accessibility issues and are designed to be quick and easy, rather than definitive. A web page could seem to pass these checks, yet still have accessibility barriers. More robust evaluation would be needed to check all issues comprehensively.

Using this page

Checks are provide for specific aspects of a web page:

  • Page title
  • Images (pictures, illustrations, charts, etc.)
  • Related to text:
    • Headings
    • Color contrast
    • Zoom and text size
  • Interaction: Keyboard access, labels, content order, visual focus
  • Multimedia
  • Forms

Tools

Most of these checks you can do with any browser, that is, you do not need to download anything.

However, some checks are easier if you can download tools. To keep it simple, we've included instructions for just two tools - the Web Developer Toolbar for Firefox ("FF Toolbar") and the Web Accessibility Toolbar for IE ("IE WAT"). Both are free extensions/add-ons available in different languages.

Note that we're not endorsing these tools over others. There are other useful tools to help with evaluation.

To learn how to do these checks with other tools, see [TBD either Web Platform Docs -or- WAI-Engage wiki].

(If you can't download these tools, that's OK; you can still do the checks indicated "with any browser".)

Practicing with BAD, the Before-After Demo

The Before and After Demonstration (BAD) from W3C WAI shows an inaccessible website and a retrofitted version of this same website with the accessibility barriers fixed. You can use the BAD pages to learn how to do these checks. For example, first, do the check on an accessible version of a page to see what it should look like. Then, do the check on the corresponding inaccessible page to see what it looks like when there are accessibility barriers.

Little Background

These checks are designed for anyone who can use the web. You don't need much knowledge or skill. To check a couple details, you need to see the visual page or hear audio. However, there are lots of things that anyone can check.

Here are some things to know that will help you understand the brief explanations:

  • assistive technologies (AT) is software or hardware that people with disabilities use to improve interaction with the web.
  • screen readers read aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities.
  • voice input is using speech instead of a keyboard and mouse.

If you want to learn more, see:

WCAG Links

These checks are based on the Web Content Accessibility Guidelines (WCAG) 2.0. The main points in WCAG are called "Success Criteria". In the "Learn more from" sections of this page, there are links to pages that explain the relevant success criteria in the "Understanding WCAG 2.0" document. For an introduction to WCAG, see the WCAG Overview.



EOWG Comments on the Introduction

  • comment {name}



back to contents

Page title

Page title in WAI draft page

EOWG Notes on Page Title

  • comment {name}

back to contents

Image text alternatives ("alt text")

alt text in WAI draft page

EOWG Notes on alt text

  • comment {name}


back to contents


Headings

Headings in WAI draft page

EOWG Notes on Headings

  • comment {name}


back to Contents

Color contrast

[Anna Belle and Sharron are editing this section. Here is the previous 1 February draft of color contrast with lots of text.]

back to Contents


Zoom and text size

People with mild to moderate visual impairments may need to enlarge content in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality.

Most browsers offer two ways of enlarging content: page zoom and text resize. Page zoom works by scaling up the page content, so that text, images, and buttons are all increased or decreased in size, and the integrity of the layout is maintained. Text resize only affects text, although implementation techniques can be used to also change the widths and heights of containers, margins, padding, and other aspects of the design.

Not all browsers offer both choices, and some browsers will not resize text if it has been set using fixed units such as pixels.

  • In browsers that support zoom, increase zoom level to 200% or maximum zoom if smaller than 200%
  • In browsers that support text resizing, increase text size to 200% or maximum size if smaller than 200%

What to do

For each browser to be tested:

  • Set the screen window to full width
  • Open your preferred browsers. Internet Explorer, Firefox, Chrome and Opera all offer zoom as a function of View or Function menus, or as a keyboard shortcut (usually, Control +, or for Mac Command +).
  • In browsers that support page zoom, enable this option and use the appropriate control to increase zoom level to 200% or maximum zoom.
  • In browsers that support text resizing, enable this option and use the appropriate control to increase text size to 200% or maximum size.

What you will see

  • For page zoom layout should remain approximately the same for fixed width designs, and will reflow in the same way as resizing the window would at small sizes.
  • For text resize most aspects of the design will not change and layout will probably not increase in size. Content will reflow appropriately within the same available space as text increases in size.

What to check for

  • Text should increase in size in both cases, addionally with page zoom all elements on the page should increase in size.
  • No content should overlap.
  • All controls must be clickable.

Note

Some browsers can expand the text beyond 200% - this is not covered by the resize requirement as it is recognised that this will cause some of the failures described. It is also accepted that some horizontal scrolling may be necessary but see also 1.4.8 which is a AAA requirement. Users with more severe visual impairments who need larger text are likely to use screen magnifiers to increase text size above 200%.

References



EOWG notes on zoom and enlarge

[See e-mail thread on zoom & resize ]

[done - 1 Feb agreed to include it] We previously thought we wouldn't include this in the easy checks. One of the issues was conflicting perspectives in forums and critiques that 200% is too hard to meet. Ian has re-drafted this section.
Please comment on reasons to include it or not. Feel free to edit the main text as well.

  • @@comment {name}
  • @@comment {Vicki} I would include this as it's well explained and sounds simple :) Often, this is a check which is quite difficult to understand but as it's explained quite clearly here, I would include it. One comment: at the end of the first section (just before "What to do"), there are two bullet points on the browsers and zooming. Shouldn't this be removed and left (as currently duplicated) in the "What to do" section?

back to contents

Keyboard access, labels, content order, visual focus

EOWG notes - importance: HIGH.
5min: maybe.
15min: yes, at least part of it.
Without visual rendering: @@

Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. While screen reader users rely on the keyboard, they are not the only ones. In addition, sighted users with mobility impairments may rely on the keyboard or have assistive technologies that are controlled through keyboard actions. Therefore, key components of effective keyboard access include visible focus indication and a logical tab order. @@ need to explain 'visible focus indicator' and 'logical tab order' - we can't just use these phrases and expect folk to understand {Andrew}

What To Do

  • Click in the address bar, then put your mouse aside and don't use it.
  • Press the 'tab' key to move around the page. @@ Alternative: Press the 'tab' key to move through the interactive elements on the page. {Andrew}
  • Use the keyboard to set the focus to all focusable elements on the page. @@ Huh?? What does this mean in comparison to previous bullet? {Andrew}

What To Look For

  • Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover or click)?
  • Does the tab order follow the logical reading order, top to bottom, left to right in sequence?
  • Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?
  • Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page out of order logically) @@ Covered in point 2? {Andrew}
  • Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)
  • If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)
  • Visually examine progress through elements and verify that the focus indicator is clearly visible (i.e. you can see where you've 'tabbed' to). @@ swap bracket for phrase before to reduce jargon? {Andrew}
    • Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.
  • Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus

References

Notes

  • Mac browsers by default only tab through forms, will need to turn on...
  • not work easily in Opera...
  • ...


back to contents


Multimedia (video, audio) alternatives

[Updated 7 February]

Check multimedia elements to ensure that visual and audio content includes equivalent alternatives and that the media player is fully accessible.

What to do

These steps will give you a quick and easy first look. They will identify that alternatives for media content have been considered and attempted. A more comprehensive testing process will be needed to verify the quality of the alternatives provided.

  1. Follow the steps for keyboard access to ensure that the media player controls are labeled and operable by all users.
  2. Play a short piece of the audio content
  3. Play a short segment of the video content
  4. Toggle closed captions on (if available) {@@ need some guidance on how to do this?}
  5. Toggle audio description on (if available) {@@ need some guidance on how to do this?}
  6. If no captions or audio description options are provided, check page for transcript or link to transcript

What to look for

Captions

  • Are captions provided?
  • Are they synchronized to the spoken content? {@@ not sure this is necessary for easy check?}
  • Has important audio content other than dialogue been included? (music, relevant ambient sounds, etc) {@@ need to say more and maybe give examples, or is that beyond easy check?}

Audio Description

{@@ think most people have no idea what this is and we need a brief explanation? Andrew: agree}

  • Is an audio description track provided? {@@ could be a separate file, not a track}

Transcript

  • If captions and audio descriptions are not provided, look for a link to a text-based script containing dialogue and other audio content and description of video needed for understanding.
  • Check for spelling and accuracy. {@@ I think spelling and accuracy is beyond quick check}

Learn more about providing alternatives for media content



EOWG Notes on Multimedia

  • Generally, we aren't addressing the levels; however, this one is complicated. Time-based Media: Understanding Guideline 1.2 has 9 success criteria, including A, AA, AAA -- eek! Ideas on how to address this? {Shawn}
    • comment {name}
  • vision and hearing needed for checks:
    • To check if there are captions, need to be able to see. [visual]
    • To check if the captions are synched, need to be able to hear. [auditory]
    • To check if audio description is provided, need to be able to see? hear?
    • other?
  • [OPEN - add back in] Auto play - it is easy to test whether the audio starts automatically. {Suzette}
  • Audio contrast - mightn't be able to say yes/no, but might be able to say 'could be a problem' {Andrew}
  • comment {name}


back to contents

Forms

SK: see email for update 11pm UK, 23 Jan.

[15: maybe not]

[drafted, edited, needs review - move keyboard access, visual focus, content order with other section ?Sharron ?Suzette]

EOWG notes.
5min: no, too complicated.
15min: not sure

Note: Some aspects will be integrated with keyboard access, visual focus, content order.

Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Several principles of accessibility should be kept in mind when testing forms. Labels for form controls, input, and other user interface components must be provided. Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. Forms may be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Clear recovery mechanisms must be provided.

Forms - simplified

[Edited by Suzette, is this sufficiently simplified?]

Note: Some aspects of Forms will be integrated with keyboard access, visual focus, content order. {SK - Also have removed references to colour coding and graphics/non text content and CAPTCHA.}

Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Forms are complex and need in depth assessment.

Some critical elements which can affect screen reader users are much easier to detect using an automatic tool to check the HTML and CSS, or as a user trial with an experienced screen reader user.

The following visual checks can identify some common problems which are particularly important when testing forms.

{There 10 Success criteria references are included to help editorial choices – is this too many? SK}

  • Labels for form controls, input, and other user interface components must be provided. (Labels and Instructions 3.3.2 A)
  • Keyboard access for people who do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. (Keyboard 2.1.1 A, No keyboard trap 2.1.2 A, Focus visible 2.4.7 AA)
  • Information needs to be in a logical order which is followed when tabbing through the input fields. (Meaningful sequence 1.3.2 A, Focus order 2.4.3 A)
  • Error correction: Forms may be confusing or difficult to use for many people, and, as a result, they may need more time and be more likely to make mistakes. Clear recovery mechanisms must be provided. (Error identification 3.3.1 A, Error suggestion 3.3.3.AA, Error prevention (legal, financial, data) 3.3.4 AA. Timing 2.2.1 A)


Are there any forms

Check through the web pages to look for examples of forms.

What to look for:

    • Forms include registration forms, contact forms, booking and purchase details which include text entry fields, radio buttons, dropdown boxes and submit buttons and also single text entry boxes such as login or search box.

Visually examine the instructions for the form and input fields

Check over each form.

What to look for:

    • Are there text instructions at the beginning of the form including if any elements are essential?
    • Are there text labels (before/after?) the input fields that describe what to do and if any elements are essential
    • {Exclude? If required fields are indicated by use of color cues, ensure that additional, alternative methods are also used – Use of colour 1.4.1 A)

Keyboard access

Use the Tab key to move through form controls, text boxes, radio buttons, drop down box and submit button. (Use shift tab to go back). Use the cursor (arrow) keys to access selection box content.

{SK: recommend refering to Keyboard access (above) and delete the rest of this section}

What to look for:

    • Is the focus visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons?
    • If the form control is a check box or radio button, ensure that focus indication includes form label as well as the actual control (SK –can you do this visually?)
    • If the form control is a select box, ensure that arrow keys can move focus between select options and that selection is made by user action and not by default focus. (SK – can you do the second part of this visually?)

Logical sequence

Compare the sequence of information presented visually with the tab through order.

What to look for:

    • Ensure that focus moves logically between the fields.
    • Enter correct and false data in form input fields

{SK: recommend refering to Keyboard access (above)}

Use the keyboard to enter data into the text field.

Enter correct and incorrect data – eg incorrectly formatted telephone numbers and email addresses.

What to look for:

    • Ensure that focus does not automatically advance to the next field, but requires user input to advance (SK – is this easy or advanced, what success criteria?)
    • When erroneous data is entered and form submitted:
    • Ensure that error message is clear and specific about the nature of the error and the field in which it was made
    • Ensure that focus moves to the error message
    • Ensure that guidance is provided to help user understand and fix the error.

{SK: recommend referring to Keyboard access (above) but would suggest keeping this practical suggestion to try filling in the form, especially with correct and incorrect information that will trigger error messages}

References

Several Accessibility Principles are relevant to the accessibility of forms, including these:

WCAG2 Guidelines and Success Criteria that may be applied to determining the accessibility of forms include these:

WAI's Before and After Demo (BAD)includes examples of forms that have been made accessible:

Notes

[can be internal notes for now or maybe will be included in final doc]

  • ...
  • Is it possible to have a 'first glance' option to identify potential trouble spots and very common problems, which can then be examined in more depth? {Suzette}
  • I have noticed some developers having trouble with single fields such as search boxes or login details, or simple little contact forms - perhaps we could expand the opening description to suggest looking for these. It is not just dedicated forms such as membership details, job applications, tax returns, travel booking and shopping etc.{Suzette}

Comments 2012-Nov-30

Shawn: Maybe, a couple of things are easy, some are complex. We could use the nice writeup somewhere else if not used here. Suzette: I can try and pick the easy bits out of Sharron's content to see if we can get this in. Shawn: Or add notes on forms to Keyboard Access and Visible Focus sections.

Next Steps

So, you've spent a little time getting a sense of the accessibility issues that need to be addressed, but what do you do next? How can you flag the problems and solutions, while being sure that the information reaches those who can make the changes happen?

If you have a bug-tracking/helpdesk system, you might use that. Or you might decide it would be more effective to write a report in which you group problems and solutions in terms of people's roles and responsibilities. [@@ JS: maybe link to WAI-Engage, even though it's in progress?]

What works best will depend on your circumstances. Regardless, you'll want to describe the issues clearly. For examples of recommendations we have developed to guide site visitors who experience difficulty accessing a web site, see a section of [Contacting Organizations about Inaccessible Websites http://www.w3.org/WAI/users/inaccessible] called "Describe the Problem." In addition, these Sources for More Information will help your colleagues familiarize themselves with additional information.

When you're ready to conduct a more thorough evaluation,either internally or by hiring a qualified contractor, the [WCAG- Evaluation Methodology Overview] (coming soon) and accompanying documents will help you develop your plans as you continue your efforts to provide a more accessible web for all.

EOWG Notes on Next Steps

  • comment {name}



Contributors

Thanks to:

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


Important Note: For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way — for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.