- From: suzette keith <suzette.skeith@gmail.com>
- Date: Thu, 24 Jan 2013 22:58:13 +0000
- To: "EOWG (E-mail)" <w3c-wai-eo@w3.org>
- Cc: Sharron Rush <srush@knowbility.org>
- Message-ID: <CAH7X45O+fQjRQNLRhkF9fd9OVEdcGDqRb_DmZSuJExDhPXcSHQ@mail.gmail.com>
Hi EOWG'sI made some small changes to the Easy evaluation Wiki for the section on Forms but it was difficult to make the necessary major changes. Here is the revised section, cross referenced to the Keyboard Access section and excess material deleted. By the way, I believe that developers are more likely to recognize the functional element of 'forms' with text boxes, radio buttons etc rather than the operational view of having keyboard access to it. But feel free to disagree! 1.4.7 Check forms EOWG notes. 5min: no, too complicated. 15min: has been simplified and cross reference to Keyboard access sections 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. 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. 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 and keyboard only checks can identify some common problems which are particularly important when testing the accessibility of forms. *1.4.7.1.1 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. Typically these will have text entry fields, radio buttons, drop down boxes and submit buttons. Also look for single text entry boxes such as login or search box. 1.4.7.1.2 Visually examine the instructions for the form and input fields Check over each form and try entering both correct and incorrect data. 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 - Ensure that any error messages are clear and specific about the nature of the error and the field in which it was made - Is color used for example to warn about errors and if so are there additional, alternatives for people who cannot see the color change. 1.4.7.1.3 Keyboard accessUse 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. See section on Keyboard access above 1.4.7.1.4 Logical sequence Compare the sequence of information presented visually with the tab through order. See section on Keyboard access above 1.4.7.2 References Several Accessibility Principles are relevant to the accessibility of forms, including these: - Text alternatives to non-text content<http://www.w3.org/WAI/intro/people-use-web/principles#alternatives> - Functionality is available from a keyboard<http://www.w3.org/WAI/intro/people-use-web/principles#keyboard> - Users can easily navigate, find content, and determine where they are<http://www.w3.org/WAI/intro/people-use-web/principles#navigable> - Content appears and operates in predictable ways<http://www.w3.org/WAI/intro/people-use-web/principles#predictable> - Users are helped to avoid and correct mistakes<http://www.w3.org/WAI/intro/people-use-web/principles#tolerant> WCAG2 Guidelines and Success Criteria that may be applied to determining the accessibility of forms include these: - Non-text Content<http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html>: Understanding Success Criteria 1.1.1 (Level A) - Keyboard<http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html>: Understanding Success Criteria 2.1.1 (Level A) - Focus Order<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html>: Understanding Success Criteria 2.4.3 (Level A) - Headings and Labels<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html>: Understanding Success Criteria 2.4.6 (Level AA) - Visible Focus<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html>: Understanding Success Criteria 2.4.7 (Level AA) - Predictable<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html>: Understanding Guideline 3.2 (Level A and AA) - Input Assistance<http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error.html>: Understanding Guideline 3.3 (Level A and AA) - Name, Role, Value<http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html>: Understanding Success Criteria 4.1.2 (level A) WAI's Before and After Demo (BAD)includes examples of forms that have been made accessible: - Inaccessible forms page<http://www.w3.org/WAI/demos/bad/before/survey.html> - Accessible forms page<http://www.w3.org/WAI/demos/bad/after/survey.html> 1.4.7.3 Notes [can be internal notes for now or maybe will be included in final doc] - Justification - we should have a section on forms because they are a major element in many websites, and my studies showed that developers get them wrong - for both simple search boxes and full interactive forms. {Suzette} best wishes Suzette
Received on Thursday, 24 January 2013 22:58:45 UTC