Edit comment LC-724 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-1049 Next: LC-864

Comment LC-724: Comment Shortname:; Commenter: Robert C. Baker <Robert.C.Baker@ssa.gov> on behalf of Social Security Administration; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):

(See LC 681 for complete submission)

The guidelines do not address the following:

Â§Search facility guidelines for navigation and focus.

Proposed Change:; Related issues: 681 721
(space separated ids); WG Notes: [TEAMB] Request for clarification sent as part of general request for clarification. GV Clarification received: SSA: Again, this is a big issue of focus. Search facilities are used extensively in web pages and applications. However, identifying the results of a Search is hit or miss depending on where the focus is applied. In some cases, after a Search is initiated, the focus is placed back in the Search input box, so the user may think that it did not work. Often, the focus is at the top of the page and the user has to tab or arrow through significant controls or text to get to the results of the Search. SSA suggests that there be a capability or guideline to move the focus to the results of a Search. That is "No Hits Found" or 1-10 of 85,000,000. Discussed in the 05 October 2006 telecon: Resolution: Accept LC-724: Search facilities as amended with action items http://www.w3.org/WAI/GL/2006/10/05-wai-wcag-minutes.html [BB] SSA's Guide to Applying Section 508 Standards â€œrepresents the criteria SSA tests for when evaluating EIT for Section 508 complianceâ€? is available for download from this page: http://www.ssa.gov/oag/acq/oagacq_508.htm The actual URL is: http://www.ssa.gov/oag/info/SSA%27s%20Guide%20to%20Applying%20Section%20508%20Standards.doc (SSA’s Guide to Applying Section 508 Standards.doc) The problematic portion is on p. 49 (of 103 pp.) with regards to 508 Section 1194.22(n). Requirements (n.1 and n.2): â€œScreen readers must speak all controls, labels, directions, and cues in a logical order. Keyboard users must get focus to all controls, labels, directions, and cues.â€? Recommended Evaluation Criteria: â€œAll direction, cues, labels, and instructions must be spoken in order to fill out a field properly. Focus must be visible on all controls, directions, and cues.â€? Their expectation is that this will occur without leaving forms mode and by only tabbing through a form. This is achieved in practice by adding tabindex values to paragraph and header elements. In practice, with the right combination of Jaws and IE, it actually works reasonable well! I have not been able to track down who discovered this technique first. My primary objection is that the feature and effect seems to be largely undocumented. If nothing else, I would like to know of a DTD that such html code could validate to. To find and example, from the SSA home page, follow the links for â€œReplace a Medicaid Cardâ€?. http://www.ssa.gov/ > What you can do Online (top left-most link under horizontal nav bar) > Get a replacement Medicare Card (second item in main middle pane). Or maybe this will work: https://s044a90.ssa.gov/apps6z/IMRC/Controller; Resolution: While this can be helpful for improving the experience with Windows Narrator, more fully-featured screen readers have the ability to allow users to interact with all kinds of text. Users of those screen readers are used to the way they interact with structured pages, and don't need this extra help. In addition, there are many issues for other types of users with this non-standard approach. For example, 1) Unexpected behavior for all users 2) Developers often attach events to paragraphs and other non-actionable elements when they have focus, and this is not compatible with AT. 3) This will be more difficult for sighted keyboard users, as they will have to tab through parts of the page that are not normally tabbable. 4) Confusing for experienced screen-reader users, because they expect that everything tabbable in a form is an editable field 5) Optimized for forms mode, but also used on non-form pages. This is very strange when in browse mode, because users expect to be able to tab to find links.; (Please make sure the resolution is adapted for public consumption)