Web and Software: Correct coding

Correct coding (Group D)

The following Section 508 provisions are grouped together for discussion purposes and address correct coding of structures and interactive components. The TEITAC Web and Software subcommittee is reviewing these for issues, gaps, and keeping in mind the themes.

Discussion of these provisions should take place on the mailing list. Be sure to include an appropriate subject line that begins with "Group D". Rewording proposals may be made by editing this page:

22(g) and 22(h)

Current wording:

• 22(g) Row and column headers shall be identified for data tables.
• 22(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

Summary of discussion on 22(g) and 22(h)

• WCAG 2.0: Both simple and complex tables are addressed in the techniques for 1.3.1 "Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies." (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/)
• Required for software - both interactive and static - accessibility APIs support. 21(d) and 21(l) seem to be the only thing currently in the software checklist that come close to supporting this.
• Required for content - added to content issues page. Suggest deferring applicability to content until we get to the content discussion.
• Current wording is testable and clear
• The WCAG 2.0 requirements may be clear to developers but will not be clear to people evaluating VPATs or testing for compliance. The 508 wording is more clear and to the point.
• Some AT and browser support issues identified with regard to exposing row/column header information and providing more comprehensive keyboard navigation. Defer to general issues discussion on AT responsibility
• Discussed at the December 6, 2006 meeting

22(i)

Current wording: Frames shall be titled with text that facilitates frame identification and navigation.

Summary of discussion on 22(i)

• WCAG 2.0: Addressed in the techniques for 2.4.1 "A mechanism is available to bypass blocks of content that are repeated on multiple Web units." (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/)
• Wording is not clear resulting in frame titles that are not meaningful
• Commercial applications that have a large number of frames (sometimes 10-15) with most of them being used for background processing resulting in navigation issues for keyboard users. Attempts to hide these "working" frames from assistive technologies has been inconsistent at best.
• Are i-frames covered? Differing views:
  • i-frames have caused issues of not being able to navigate to them with screen readers.
  • i-frames are read and accessed as if they were inline content. They do not require the title element as it is not necessary to have this information to navigate to them.
  • Titles for iframes are helpful in providing context about what the page includes, especially if there are multiple iframes on the page. When no title is provided, the user may only receive information that there's "one frame" or that they have reached "ifrm" (pronounced something like iffrim by screen readers) if they navigate to the frame via tabbing.
• Are invisible frames required to have identification, or should those be explicitly labeled with a null title until made visible, when the label must be changed?
• Discussed at the December 6, 2006 meeting

22(o)

Current wording: A method shall be provided that permits users to skip repetitive navigation links.

Summary of discussion on 22(o)

• WCAG 2.0: addressed in 2.4.1 "A mechanism is available to bypass blocks of content that are repeated on multiple Web units." (Web Content Accessibility Guidelines 2.0, http://www.w3.org/TR/2006/WD-WCAG20-20060427/, 27 April 2006, W3C Working Draft. Latest version at http://www.w3.org/TR/WCAG20/) So WCAG 2.0 is broader than 508. It applies to any kind of repeated content, not just navigation links.
• Testability issues:
  • "repetitive" is subject to interpretation.
• Skip links or page structure (headings, lists, frames) are both interpreted as meeting the requirement.
  • Skip links work well only for screen reader users. Most browsers change only the visual focus, not the keyboard focus so sighted keyboard-only users do not really get the function.
  • If a skip link is used, it should be one of the first things on a page. If the skip-nav link at position ten or more, after the links one is intended to skip, then it doesn't meet the requirement. "Skip link" techniques could explain this.
  • Screen readers will now figure out the repetitive navigation links and skip them automatically without developers doing anything.
  • Screen readers and some browsers also now provide heading navigation so a page that has visible headings that are marked using <hx> elements meets this requirement.
    • Note: Visible headings are required to be marked with <hx> elements by WCAG 2.0 1.3.1 "Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies." and this is sufficient to meet WCAG 2.0 2.4.1 (above).
  • What about grouping links using list elements or frames? Frames work well and are accessible to keyboard users.
    • W3C User Agent Guidelines Checkpoint 9.9 in fact require user agents to "Allow the user to navigate efficiently to and among important structural elements in rendered content" (User Agent Accessibility Guidelines 1.0, http://w3.org/TR/UAAG10 W3C Recommendation 17 December 2002)
• HTML could be enhanced to allow semantic identification of repeated content. Then user agents could reliably provide this function.
• Should this require a "visible" mechanism?
  • Even with the current 508 requirement, there is much resistance to even one visible skip link
  • If we broaden this to all repeated content or between sections of a page, it will introduce a lot more links which increases cognitive load.
  • Proposal: When repetitive links, or multiple sets of repetitive links are present on a web page, a visible method to change the focus to major content, or by-pass repetitive links must be provided accept when repetitive links provide this functionality.
• Maybe we need a higher level requirement - quick keyboard focus movement around a page as a whole. It is important to be able to find (get to) different sections of a page, independent of whether the stuff in between is repetitive or not - even if you can't see the page or use a mouse.
  • Be careful of tabindex. It only seems to work reliably when every element on the page has one.
  • Proposal to use "navigate among"
  • Proposal: Provide mechanisms whereby keyboard users are able to navigate to major sections of each page.
    • determining the "major sections" may be a testability issue. Suggestion to look at the work currently being done by the protocols and formats working group on assigning roles to parts of pages.
• Discussed at the December 6, 2006 meeting

22(d)

Current wording: Documents shall be organized so they are readable without requiring an associated style sheet.

Summary of discussion on 22(d)

• WCAG 2.0: Not a requirement in WCAG 2.0 because it is a baseline issue. If CSS is in your baseline, then the page doesn't have to work with style sheets disabled. If CSS is not in your baseline, then it does.
  • Even if CSS is in the baseline, the content should still support the user overriding the page style with their own styles. WCAG 2.0 1.3.1 is meant to support this requirement "information and relationships conveyed through presentation can be programmatically determined, and notification of changes in these is available to user agents, including assistive technologies.
  • You never disable all style sheets. You simply revert to the browser's default style sheet.
  • The underlying concept that led WCAG 2.0 to "baselines" is to allow guidelines to be written that:
    1. work as technologies evolve
    2. are not impossible to meet today
    3. are not ineffective today (i.e. don't provide real accessibility).
• The term "document" implies that this provision may not apply to web applications, either way this should be clarified.
• The use of "readable" in the requirement is a testability issue. All pages are "readable" with the style sheets disabled. The intent of this requirement is that the reading and navigation order and structure of the content is logical and operable when styles are disabled.
  • See also General issues reading order discussion related to 22(d).
• Proposal: Information and content shall be structured in a way so that it meets all conditions of this part (meaning whatever else we come up with) when visual styling is removed.
• Discussed at the December 6, 2006 meeting

Other

Jonathan: I believe 1194.21(l) also applies to this grouping.
For example, correct coding of scripting can prevent or deny keyboard access to users.