EOWG: preliminary evaluation - changes to section on forms

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