Introduction
Web 2.0 entices web authors with dynamic capabilities, but these advances in performance and functionality have proven a barrier to a growing contingent of users. Many interactive web elements, including forms with dynamic updates and error validation, can be disorienting to users and inaccessible to blind people who use a screen reader to access the Internet. Several of the most challenging barriers to web form use include:
- Relationships among form elements
- Keyboard navigation to and within forms
- Required field and validation feedback
- Handling of dynamic updates to a form
With an emerging specification from the W3C, developers of rich internet content may no longer have to choose between modern interactivity and accessibility compliance. The W3C’s Web Accessibility Initiative is producing the Accessible Rich Internet Applications specification (WAI-ARIA). WAI-ARIA defines element roles, states, and properties similar to desktop software terminology. Despite disparate coding implementations, the consistent element types (roles) and their states may be rendered to browsers and to screen reader users, providing consistency in the users’ web experience. Although designed for full, rich applications, WAI-ARIA techniques can be hugely beneficial to humble web forms. We will illustrate the benefit by showing before and after examples for the form challenges previously listed.
WAI-ARIA code is a progressive enhancement: if the user’s browser does not support the standards, or if the user has older assistive technology, the WAI-ARIA code is simply ignored. With the addition of relatively simple WAI-ARIA code, web forms can be made more usable for all, especially people with disabilities.
Form Control Relationships
One aspect of web forms that has been difficult for screen reader users to discern is the relationships among form elements. One of the most basic aspects of a relationship is a control’s name. W3C WCAG 1.0 Checkpoints 12.4 and 10.2 require form inputs to have a correctly positioned label explicitly associated with an input control.
In addition to clearly identifying a control, a label also increases the clickable area for an input field. In “Accessible Forms using WCAG 2.0,” Hudson notes that labels are particularly helpful for mouse users with diminished vision or fine motor skill difficulties.
With a text input, clicking anywhere on the label or textbox will put the cursor at the beginning of the text input area. Similarly, a radio button or checkbox can be checked by clicking either the label or button (or box).
Universal use of labels, while accessible, is not optimal in cases where a visible label is not desirable, such as an ordinary Search form. The submit button may have a value of “Search” and a separate label would be redundant. The following example shows a typical layout of an edit box with a Search submit button after used with Freedom Scientific’s JAWS screen reader:
Figure 1. Search form example and HTML code.
input type=”text” name=”search” title=”Search criteria”
As a screen reader user navigates to the form and focus reaches the text box, JAWS version 10 reads: Edit. Type in Text.
When the user presses the down arrow key to continue, JAWS reads: Search button
In this example, the screen reader user does not know the edit field’s purpose until after moving focus beyond the field itself. This is not intuitive.
In WCAG version 2, the label requirement is relaxed somewhat and accommodates the case where you do not want a visual label. WCAG 2.0 Success Criteria 1.3.1 and 3.3.2 require that:
- Structural relationships be conveyed programmatically or be available in text.
- Labels or instructions are provided when content requires user input.
To comply with WCAG 2 without adding redundant visual or auditory text, simply add a title attribute to the user input field. In this case, JAWS reads: Search site. Edit. Type in text.
When you press the down arrow to continue, JAWS reads: Search button
Hearing the contextual cue prior to the input control, the screen reader user can better perceive the form and its use.
Note: A number of screen readers exist on various platforms. On the Windows platform, the two most common are JAWS and WindowEyes. JAWS 10 was used for these examples.
Figure 3 and 4. STC AccessAbility SIG blog.
Web Page Landmarks
Let’s think about a screen reader user who wants to move around a complex web page—perhaps something like a typical corporate intranet. In addition to its main content, the page might include a:
- Banner with corporate branding
- Menu bar offering hierarchical choices
- Navigation bar containing a tree structure
- Form to search text on the intranet
- Form to search a corporate directory to find other employees
Let’s consider navigation on a public website that contains multiple forms, the STC AccessAbility SIG blog site located at http://www.stc-access.org/. To accommodate users with low vision or who use screen magnifiers, the site is designed with the main content at the top and left, below a banner. The interactive elements, including several forms, are located to the right.
A screen magnifier user might not see the utilities, or would have to manually scroll the screen image to the right to make the utilities visible. Similarly, if a screen reader began in Say-All mode, the other elements would be announced only after reading through the current main content. To get to the right place, a screen reader user might have to frequently tab over irrelevant material. One well-known technique is to provide a skipnav to skip over repeated content and go directly to the main content. (Jim Thatcher’s website has a particularly good coverage of this topic at http://jimthatcher.com/skipnav.htm). But this does not help the user who wants to go directly to the Search form.
Another strategy is access keys such as Alt+H to go directly to the Home page. But access keys introduce more problems than they solve. Many key combinations are already reserved, particularly for users of assistive technologies. Years ago, John Foliot compiled a list of known reserved keystroke combinations, demonstrating both the lack of “available” options and the potential for collisions. (See “Accesskeys and Reserved Keystroke Combinations,” WATS.ca website. Available: http://www.wats.ca/show.php?contentid=43.)
The addition of WAI-ARIA roles could aid screen reader and screen magnifier users as well as anyone navigating with a keyboard. WAI-ARIA includes a conceptual role of landmark to identify sections on the page with a specific purpose, such as navigation aids or search forms. By identifying semantic regions, web authors enable user agents and assistive technologies to provide consistent navigation among them. Freedom Scientific’s JAWS screen reader version 10 announces ARIA landmarks and provides shortcut keys:
- Semicolon moves to the next landmark on
the page - Shift + semicolon moves to the prior landmark on the page
- Insert + Ctrl + semicolon presents a list of available landmarks
Landmarks include seven specialized regions, each distinguished by a different WAI-ARIA role. (See “Landmark Roles,” Accessible Rich Internet Applications (WAI-ARIA) Version 1.0. Editor’s Draft, 10 February 2009. W3C. Available: http://www.w3.org/WAI/PF/aria/#landmark). The search and application roles are of particular use in forms. To indicate that a form’s purpose is to provide search functionality, the author simply adds role=“search” to the element.
Now, let’s add landmark roles to the STC AccessAbility SIG blog site. Figure 4 shows the addition of banner, main content, navigation, two search, and content description regions.
We have enabled JAWS users to move quickly among the major regions on the page and to the forms. Note that two elements share the role of search. A label or other prompt could distinguish between a site search, an archive search, or other targeted search form. By including landmark roles, we provide both easier navigation for all and additional semantic cues for assistive technology users.
Figure 5. Form used for entering a full name.
Form Properties and Validation
Most web users have struggled at some time to submit data in a web form where either the required or unavailable elements were not clearly indicated or where invalid data submitted is not clearly identified. When you submit a web form, you invoke an implicit trust that the web author will accept the data and treat it kindly. You believe that you have been informed of which fields require values.Traditionally, authors indicate required fields with an asterisk or perhaps a graphic with the alternative text “Required Field” to accommodate screen reader users. A CSS class attribute might dim the appearance of fields not currently available. W3C WCAG version 2 compliance requires that form fields must be so marked and, if a symbol is used, that the user is advised of its meaning before first use. (See “H90: Indicating Required Form Controls. Techniques for WCAG 2.0.” W3C. Available: http://www.w3.org/TR/WCAG20-TECHS/H90. html). WAI-ARIA offers to remediate these deficiencies with its aria-required property and aria-invalid state. Consider the example in Figure 5 for a form collecting the full name.
Paragraph text before the form fields does with an asterisk. However, if a screen reader user navigates to the form using the Tab key, rather than in Say-All mode, this important text could be missed. In this case, when focus reaches the first text field, JAWS reads: First star colon. Edit. Type in text.
Next, let’s use WAI-ARIA to tell the user what is required. We add the code aria‑required=“true” to the required input fields.
Now, JAWS reads: First star colon. Edit. Required. Type in text.
The code addition is minor, but the impact to a screen reader user who does not hear the introductory text announced can be significant. With a more complicated form, the pain of submitting the form then having it rejected on form validation can be significant.
Handling Dynamic Updates
You entered the required data and you submit the form. You expect confirmation if all is well and feedback on any corrections is needed. User friendliness requires that we retain any valid data and provide cues to any needed corrections (incomplete required fields or values in an invalid format). With the onset of dynamic HTML, authors began to validate data entry at the form field level or to provide a summary of issues. However, such dynamic updates were often lost or disorienting to screen reader users. For example, in a simple login form, if a user omits required data, text displays inline to show what’s missing.
Without some event-driven intervention, the change is not announced to screen reader users. The screen reader simply starts reading the page again from the top. A better result would be to start reading at the point the text changed, in this case, the text, “Please correct all errors and omissions.”
One of WAI-ARIA’s greatest contributions is the notion of live regions. Currently, when a section of a web page receives a dynamic update, the change is often not announced to screen reader users. Without some visual or audible event, low vision or cognitively impaired users may not note the update. In web forms, this is particularly onerous where a selection in one control results in a change of options in another control, such as a listbox selection that results in the population of another set of choices. Now, web authors can code elements with the WAI-ARIA properties aria- live=“assertive” so that assistive technologies will notify users of updates immediately (other live region properties are less disruptive). Use of live regions is a complex topic and its support is still emerging. Its full discussion is beyond the scope of this article; it is raised here to show how WAI-ARIA aides form validation.
Current Support for WAI-ARIA
As with any new technology, WAI-ARIA is great in theory, but its practice will only prove valuable if the user agents and assistive technologies render its value. Because WAI-ARIA is a new specification, there is a bit of a chicken-and-egg dilemma. Some support is already available in the major browsers—Firefox 3, Internet Explorer 8, and Opera 9.5—as well as market-leading screen readers (JAWS, Window Eyes, NVDA). The Paciello Group has conducted extensive tests for ARIA role support; see their blog at http://www.paciellogroup.com/blog//?p=100.
However, until WAI-ARIA becomes a W3C Technical Recommendation, planned for later in 2009, support will remain varied. To learn more about WAI-ARIA and to review public working drafts, go to the WAI ARIA Overview (http://www.w3.org/WAI/intro/aria).
Conclusion
Independent of the actual elements used, with WAI-ARIA, the author specifies the role, state, and properties of elements in the web form or application. While a listbox is readily recognized with a select statement, authors have many different ways of implementing a tab panel, such as that used in a multi-page form. Despite widgets being coded through different means, the consistent use of WAI‑ARIA roles, states, and properties, and the keyboard interaction specification, will help all users find greater predictability across dynamic web material.
Retrieved from https://oldmagazine.uxpa.org/new_standards_screen_readers/
Comments are closed.
