Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional and up-to-date details on the updates to section 508 and section 255 can be found at the Access Board web site.

Web and Software: Web Gaps

Web and Software > General Issues

Contents

Focus Indicator

Do we need a requirement for a focus indicator in Web content? Discussed at November 6, 2006 conference call. See the mailing list thread on focus indicator for Web content.

Summary of discussion on a focus indicator for Web content

  • Note: the more general topics of "platform software", "application software" and "assistive technology" are deferred until we get to the topic of operating system requirements.
  • Some think a Web provision isn't necessary because it is the software that renders the content, such as browsers, applets, and plug-ins, that controls displaying and exposing the focus indicator.
  • Others think it is necessary in the Web part:
    • "Simulated" controls such as menus created with JavaScript and div elements and Flash content can be problematic with regard to the keyboard focus. The need for web based material to properly identify focusable material to the browser is necessary.
    • Standard HTML Web content also has issues around enabling keyboard users to have focus established in application logical positions. Some specific examples follow:
      • When a web page allows for the conducting of a search of the site or its corresponding database which results in the delivery of a search results page, the focus should be forced to the beginning of the search results.
      • When forms are refreshed after being submitted on-line which contain error messages resulting from that submission, the focus should be forced to the beginning of the error message displayed on the page.
    • Hierarchies of tabs are also a problem.
    • Shifting of focus into and out of applets and plug-ins is also an issue.
  • The ability to copy text from Web pages using the keyboard is also required. But browsers are required to do this per 21(a) in order to conform to 508. Do we really need to add anything to cover this case?
  • Should we consider what user-agent items should be developed that *must* be available to ensure some accessibility level based upon the other layers? If so, would this fall possibly in to a sub-portion of software/OS? For example a framework might be something like:
    • When software is used to interpret and present (insert standards for web and other associated content streams), (insert requirement beyond other software requirements).
    • Would need to supplement this with "sufficient techniques".
  • Should also cover focus being forcibly shifted without user knowledge.
    • Note that WCAG 2.0 has two provisions to address unexpected changes of context:
    • Sometimes the AT takes control of the focus and moves it.
  • Maybe we also need to address sufficient information in the web standard similar to 1194.21D.
    • Note that WCAG 2.0 has a provision to address name, role, state, properties, and values:
      • For all user interface components, the name and role can be programmatically determined, states, properties, and values that can be set by the user can be programmatically determined and programmatically set, and notification of changes to these items 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/)
  • Discussed at the December 13, 2007 meeting

Logical Reading Order

Do we need a Web requirement that addresses logical reading order? Some think reading order is addressed under 22(d) but this doesn't cover reading order of image map hot spots. Maybe we should consider expanding 22(d) to cover the image map scenario.

Summary of discussion on logical reading order

  • Note that WCAG 2.0 does have a provision at Level 1 addressing reading order: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (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/)
  • In prior discussion, some thought that reading order was addressed by 22(d) (Documents shall be organized so they are readable without requiring an associated style sheet. ). We agreed to recommend removing 22(d).
  • Jim Thatcher has an action item to develop a proposal on structure and/or reading order instead. If Jim's proposal doesn't include reading order, do we need to add one similar to what is currently in WCAG 2.0?
  • Reading order was addressed in the UNIX Accessibility API via our AccessibleRelation interface.
    • Relations are used to indicate labeling (e.g. "this static text field labels that edit text field") and also used it for document flow. So in places where the document flow is not obvious, we use the "flows" relation to indicate document flow or "reading order".
    • Perhaps a mechanism like this would be one sufficient technique for addressing this WCAG 2.0 provision - at least when the information is to be exposed to assistive technologies.

Keyboard Operation

  • Do we need a Web requirement on keyboard operation?

Summary of discussion on keyboard operation

  • Note that WCAG 2.0 has one: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying task requires analog, time-dependent input. (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/)
  • We have to walk through how it is done carefully due to the overlapping layers of technologies, but the basic requirement is definitely needed. Today, it is mostly needed when scripting languages are used to create interface elements, otherwise any lack of keyboard navigation is generally directly related to the user-agent.
  • At the present the keyboard requirement (1194.21a) is one of the most misunderstood requirements primarily due to its wording. The typical response we see on VPAT's is that mouse keys are supported. Secondly, it also needs to be included in the web requirements. Additional considerations include:
    • Logical tab order
    • Hotkeys/access keys - when to use, browser conflicts
    • Testability - number of keystrokes to be comparable to mouse navigation
    • Voice navigation - should it be separate from keyboard requirement
  • One of the advantages of using WCAG provisions is that there is a support document (understanding WCAG) that provides easy to point to descriptions, examples and techniques that are sufficient to meet the guidelines as well as known failures. MouseKeys for example, are specifically noted as not sufficient to meet this guideline. The Understanding doc never modifies the guideline but helps tpeople less familiar understand what the rest of us would.
  • Discussed at the January 3, 2007 teleconference.

Keyboard operation proposal and summary of discussion

  • Proposal: For Web content or applications that are designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
  • "discerned textually" is confusing (from discussion of keyboard requirement for software). This was put into 508 to exclude things like freehand sketching on a tablet.
  • Discussed at January 10th teleconference.

Updated keyboard operation proposal and summary of discussion

  • Proposal: For Web content or applications that are designed to run on a system that has a keyboard interface, product functions shall be executable from a keyboard interface where the function itself or the result of performing a function can be described in words.
  • "described in words" is still too ambiguous.
  • Alternative proposals:
    • For Web content or applications that are designed to run on a system that has a keyboard interface, product functions shall be executable from a keyboard interface except where the nature of the function requires continuous or analogue control (e.g. a pen or joystick), or other input which cannot be finitely described.
    • For Web content or applications that are designed to run on a system that has a keyboard interface, product functions shall be executable from a keyboard interface except where the function requires time-dependent analogue input.
      • time-dependent analogue input means it is analog in nature (not a discreet item) and has a time dependent aspect to it (so you can't just type in numbers to specify an analog number).

Contrast

  • Do we need a Web requirement on contrast? If so, it should be harmonized with whatever we do in software.

Summary of discussion on contrast

TBD

Page and element refresh

Web page and element refresh resulting from user action - Entire page or parts of the page refreshing when user takes some action such as selecting an item from a drop-down list. Savvy developers have created ways to address this (e.g., have the refresh point to an anchor tag near the element that caused the refresh so the assistive technology picks up from there) This will become more important with rich Internet applications and ability to change screen elements without server calls. No clear synergy with existing standard – maybe some synergies with 1194.21 c (input focus). (Source: Kate Walser, October 22, 2006)

Summary of discussion on page and element refresh

  • Web page and element refresh resulting from user action - Entire page or parts of the page refreshing when user takes some action such as selecting an item from a drop-down list.
  • Savvy developers have created ways to address this (e.g., have the refresh point to an anchor tag near the element that caused the refresh so the assistive technology picks up fromthere)
  • This will become more important with rich Internet applications and ability to change screen elements without server calls.
  • No clear synergy with existing standard – maybe some synergies with 1194.21 c (input focus).
  • Do we need an additional requirement to address this situation?
  • This goes directly to the heart and problems now being encountered with "web 2.0" "AJAX" web applications. Adopting something specifically from 1194.21(c) seems like the logical starting point.
  • If we better defined "functional text" in 22(l), we could cover this. As it is now, no one really knows what functional text really is.
  • Discussed at the January 3, 2007 teleconference.

Hidden Elements

Elements that are hidden visually, but rendered by assistive technologies - Elements that are hidden from view but still available to the assistive technology due to how the page has been coded (e.g., display:none means it may not show up in the visual version of the site, but the assistive technology doesn’t interpret display:none and will still present those elements to user). An example is a show/hide toggle feature where the user with assistive technology never really has the “hide” option since the assistive technology still finds the “hidden” elements. Framework-generated sites (e.g., portals) have this problem to a larger extent when lots of extra code is included and the assistive technology picks it up. (may have potential synergy with 1194.22 d (info about identity, function, etc., of element)). (Source: Kate Walser, October 22, 2006)

Summary of discussion on hidden elements

  • Do we need to recommend adding a requirement to address this situation?
  • Whether it would be modifying such codes or using other alternatives the situation needs to be addressed.
  • It used to be that screen readers ignored display:none and visibility:hidden styles. That is not true anymore at least with the last two versions of JAWS and Window-Eyes. These both respect these styles.
  • There were lots of implementation details that impacted whether JAWS ignored these, such as how the CSS was referenced in the HTML (@import, inline css, using the link element, etc.).
  • AT should honor the intent of display:none, which is to not voice content styled with that, but I'm not sure how that would fit into a guideline. I can see how it might fit into an accessibility API whether the information is available to AT from the user agent though.
  • Discussed at the January 3, 2007 teleconference.

Error Handling Techniques

Error handling is a frequent function in web and software applications that often gets neglected in specific Section 508 standards/requirements. Pop-up messages for errors are usually handled well by assistive technologies. However, errors that are indicated at the top of pages (typically in red) or by red error graphics next to fields in errors create significant issues for people with disabilities. Users typically do not know that they have errors and if they do, getting to the errors to correct is difficult at best. Error detection and correction is certainly not comparable to sighted and mouse users. (Source: Mike Fratkin, October 23, 2006)

Summary of discussion on error handling techniques

  • Do we need to recommend adding a requirement to address this situation?
  • If we address focus problems, and logical reading order, this one will fall in line. We might certainly consider using error pop-ups as an example in the language of something that would require attention.
  • AT is able to handle pop-up messages (at least in their own windows) because there is sufficient semantic information (or meta-data) available to the AT to determine this.
  • In most GUI systems there is a small collection of styled dialog boxes - "message box", "alert", etc., whose role can be determined by the AT via operating system API calls.
  • If we do decide to address this issue in 508, we should consider doing so with web document structure or WAI ARIA meta-data tagging, so that web authors can directly indicate that some portion of the web document/web application is acting as an alert of some sort. That information must then be conveyed to the AT via the user agent in some fashion (such as via DOM events exposed via some special API that the browser implements and the AT is using; or via a general desktop accessibility API).
  • Discussed at the January 3, 2007 teleconference.

WCAG 2.0 error handling requirement and summary of discussion

  • Proposal: If an input error is detected, the error is identified and described to the user in text.
    • WCAG 2.0 provides several strategies (also known as sufficient techniques) in the "How to meet" information for this provision.
  • WCAG 2.0 provides some good direction and techniques but what is missing is a means for screen reader or keyboard users to quickly navigate to the field in error.
    • Is this accessibility or usability? It is usability but when the focus is at the top of a form, it is difficult or impossible to find the fields in error. Perhaps a shortcut key combination could be provided to change focus to the field in error. As an alternative, a list of links to the fields in error could be provided.
    • What about forms where multiple fields are in error?
    • In our discussion on the requirement to skip to main content, we concluded that local links inside the page are not a good idea and don't actually work in some browsers. Would it be better to instead provide some semantic information to AT that can then be used to provide the navigation function to the user? Such semantic information is being defined as part of the W3C ARIA work.
  • Does it have to be in text or can it be "in the most appropriate/accessible manner"? For example, in a speech interface, speech might be the most appropriate. Error feedback should be in the same modality as the content. But text is always needed in order to be able to provide an alternative.
  • Discussed at the January 10th teleconference.

Valid and Well-formed Code

Besides meeting the standards we recommend, for an application or Web site to work as expected, especially with an assistive technology, it must have valid and well-formed code. (Well-formed meaning tags are closed appropriately, nested as appropriate, etc. Valid meaning the code uses only tags included in the document type definition, etc.) Problems are arising when developers fail to check their code, and more frequently, when they use frameworks (e.g., portals, etc.) to generate code for them. As a result, we’re seeing code that contains unclosed tags, poor syntax, deprecated tags, etc., that the assistive technologies can’t interpret. The end result for users is that the page is either completely or partially unreadable.

In some cases, automated 508 testing tools will see no problems with the page as they’re just looking for specific tags, so agencies and even some 508 specialists unfamiliar with the problem / who do not do manual testing as well, miss the problem entirely and consider the app/site accessible.

The issue arose during WCAG discussions with the final decision being to require "well-formed" code but not "valid" code.

Do we need a similar standard to address this issue in Section 508?

(Source: Kate Walser, December 18, 2006)

  • Discussed at the January 3, 2007 teleconferences
  • Proposal: Web pages created using markup languages have elements with complete start and end tags except as allowed by the specification and are nested according to specification.

Summary of discussion on proposal for valid and well-formed code

  • On the web gap page there was a question if 508 should address the issue of valid and/or well-formed code. I believe that it should. In Florida, the law now says follow 508. It was a legal decision. Standards are based on 508. I still see web sites without a dtd. How can such a site even be tested? I use standard valuators such as dreamweaver provides. It uses the dtd, if I'm not mistaken to validate the code. Can we test well-formed but not valid? If yes, what is used to test well-formed. I believe standard based coding is a first step to "accessibility" - not that I equate the two. But if the code is not validated, how can an accessibility tester be reliable if can even be used. It seems like 508 is concerned with testability.
  • We discussed the idea of adding a provision in 1194.22 on valid and well-formed code but did not come to consensus on it. There was some opposition to the WCAG 2.0 wording which used the phrase "parsed unambiguously" and was viewed to be hard to understand.
    • This week, the WCAG working group came up with the following more understandable wording for this requirement:"Web pages created using markup languages have elements with complete startand end tags except as allowed by the specification and are nested according to specification."
  • Recommendation to get input from developers on this one. Reality is that there's a lot of wiggle room out there, and user-agents handle that in quite a range of ways, from strict, to very loose. We should set the bar for "accessibility", lets make sure we don't support that bar with external factors that are already being managed successfully without great burden.
    • Freedom Scientific Developers say: "This isn't really much of a problem for us anymore now that we're using the DOM to parse the HTML for us. When the HTML is invalid, IE makes some decisions in an effort to make it valid. So by the time we see it, for the most part it is valid. In those cases where it is not, we already have code in place to deal with this.
    • The concern is that if the code is not well-formed, the browser has to guess how to fix it and different browsers may fix it differently.
  • If dealing with less-than well formed HTML content being provided by user-agents is a great burden on At developers, what would they find the benefit from lower that bar be? I suspect it would be little benefit for them as they will have to keep dealing with invalid content coding in any event to provide a real level of assistance to end-users.
  • An example of this would be the functionality built-in to screen readers to associate table headers to columns or rows in Word formatted files which don't provide for this ability. The end-user has to identify the items and then the screen reader can "recall" that binding. Tables are so often encoded in HTML poorly, not including the binding of headers/cells and AT vendors are getting increasingly good at overcoming the problem on their own.
  • Discussed at the April 18, 2007 meeting.

Animation

Graphical text as navigation components

  • Using graphical text as navigation components is an issue for low vision users who need magnification but are not using AT. See Jamie's post on April 20, 2007

Summary of mailing List discussion on graphical text as navigation components

  • Some browsers support magnification of images.
    • IE 7 scales images as well as text. Readability of the enlarged image is dependent on the resolution of the original image.
    • Opera scales images as well
  • Should we push user agents to provide magnification of images? It's easier to solve the problem in the browsers because there are fewer developers creating them than there are developers creating content.
    • Even if browsers all provide magnification of images, content authors need to provide images with adequate resolution.
  • Concern that users cannot upgrade to IE7 because agency IT infrastructure doesn't support it yet. This is a general problem and extends beyond browsers. Sometimes agencies purchase AT for employees only to find out they can't install it because it's not allowed by the IT infrastructure. While this is a valid problem, it is out of scope for the technical standards and users should be able to get the technology they need under Section 504.

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University