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:General issues

Contents

Requirements for operating systems?

  • Should we have a separate set of requirements for operating systems and another that covers software applications and Web content/applications or should we follow the lead of the ISO standard which includes some provisions that are specific to operating systems (or platforms) and some that are applicable to both platform and application software?
    • See Allen's comment on this topic
    • Platform and application issues
    • Web developers are responsible for exposing the focus indicator to whatever platform they are developing for.
    • UAAG may be helpful in defining the responsibilities of user agents which are a special case of "platform". See also discusion on browser requirements below.

AT-IT Interoperability

Proposal Draft 3, April 2, 2007

Proposal Draft 2, January 31, 2007

Proposal Draft 1, December 6, 2006

Equivalent Facilitation

  • Speech engines are being incorporated into electronic forms to speak elements on the screen seemingly replacing the need for screen readers. This typically is not equivalent to the functionality of screen readers and normally does not interface with refreshable Braille displays. The implementation of speech engines in meeting Section 508 compliance needs to be explored.

Summary of discussion on equivalent facilitation

  • Does the speech interface support ALL of the product functions. If not, it's not "equivalent".
    • In practice, they usually do NOT provide full access
  • Screen readers provide a lot of customization type function - changing the rate of speech, repeating things, etc. If the product speech interface doesn't provide these things, is it really "equivalent"? Do we need to define standards for this?
  • In this scenario, you don't get Braille support.
    • Braille support is more difficult to achieve than self-voicing
    • Have to be careful with this - may not be an appropriate requirement to enforce on all software (cell phone software for example).
  • Problems with interference with AT so don't meet 21(b).
  • Increases the burden on the purchasing agent on the purchasing agent to identify the accessibility issues and increases the burden on the developers to duplicate the same resources that might already be provided in the operating system.
  • Conflicting goals
    • want to encourage more and more built-in accessibility in the products but
    • have to also have the interoperability with AT to increase the likelihood that an individual user's needs can be met.
  • Proposal (not sure what this is a proposal "for" but I think it is for modifying the functional performance criteria)
  1. that products need to be accessible either via available assistive technology or directly accessible.
  2. that products that require productivity (e.g. workstations) need to b accessible to assistive technologies to allow matching of user abilities necessary to achieve high levels of productivity.
    • Concern with what "products that require productivity" mean
    • Clarification that it means workstation. Example is something that someone uses all day to perform a job vs. an information kiosk. If it takes you 4 times as long to find a room via a kiosk, it is inconvenient. But if it takes you 4 times as long to perform an action that you do all day long on your workstation, then it takes you 4 days to do one day's worth of work.
    • The point is that it should be still be required to be compatible with AT even if it provides a built-in speech interface unless it performs to the same level as AT.
  • Alternative Proposal:
  1. that products need to be capable of being used by people with disabilities either via available assistive technology or directly accessible.
  2. that products that require productivity (e.g. workstations) need to be capable of being used with assistive technologies to allow matching of user abilities necessary to achieve high levels of productivity.

AT responsibility to support what 508 requires IT to do

  • Many times, the software or website provides information that the AT does not render to the user. 508 is not clear on the AT's responsibility.
    • Screen magnifier users also need row/column information when focused on a cell. Screen magnification AT could provide it but most don't.

Summary of discussion on AT responsibility

  • Related issue is when authors use off the shelf conforming products and assume their content will conform. For example, they don't provide the row and column header information even thought the IT and AT products both support it.
  • Currently the government, as a large AT customer, has placed requirements on the AT vendors for the technologies they are using (Java, terminal emulators, Citrix, etc.) but there is a lag time when users with disabilities do not have access.
  • Issue of whether or not AT should conform to 508. Note that conformance is out of scope of the TEITAC mission. TEITAC is charged only with recommendations on the 508 standard.
  • Discussed at the January 10th teleconference.

Browser Requirements

  • Some feel that browsers should provide more keyboard navigation of Web content for those who do not use an AT.

Summary of discussion on browser requirements

  • 3 issues
    1. Performing all mouse operations with the keyboard. 21(a) requires this. Example is using the mouse to select text for copying.
    2. Performing sophisticated keyboard navigation of HTML content. This is a question of efficiency or usability.
      • Screen reader users have the best key keyboard navigation support.
      • Screen magnification users have some but not as much keyboard navigation support although they could provide more.
      • And keyboard only users who don't use AT have no support.
      • Do the User Agent Guidelines require user agents to provide this type of navigation?
    3. Entering and exiting non-HTML content. Note that WCAG 2.0 has a provision that addresses this case.
  • Do we really need to single out browsers?
  • Discussed at the January 10th teleconference.

Remote Access

  • Should we consider adding in remote access as some special set here? Citrix, X Windows, RDP, etc are primary drivers for accessibility and depend on the server end providing the accessibility attributes.

Summary of discussion on remote access

  • What about mainframe type applications that are rendered on dumb terminals. The applications are character based and only display attributes are provided, such as whether or not a field is protected or is an input field. There are no semantics provided. AT can't run on dumb terminals but these applications may be accessed by AT on other platforms such as Windows using emulator software. But most of the existing software requirements do not work for these types of applications.
    • there are lots of terminal types, but as they are sort of "legacy" technology maybe only a limited broad set of requirements are needed. VT100(s) type terminals are vastly different than 3270 type terminals, so broad may not work for all of them well.
    • even though they are legacy, federal agencies have tons of these types of applications.
    • the emulators are subject to 508 conformance but the character-based application rendered inside the emulator workspace doesn't seem to be. Is this part of the content issue?
  • HFES 200 approach:
    • Software used on, or intended to be used on closed systems should be evaluated in conjunction with the intended hardware configuration and conform to all clauses except section [that contains the provisions regarding exposure of information and control to AT].
    • Server software (used in client-server and mainframe environments) should be evaluated in conjunction with the client (including terminal) software that will be used with it.
  • Thin clients like Citrix, RDP, and X really need to be addressed.
    • Note the difference between thin clients and plug-ins: thin-clients which could be a plug-in, are intended to pass interfaces to the remote user rather than only interpret a protocol for one limited format. There are some applications such as some e-learning players, which are close to the boundaries however, and we might consider e-learning plug-ins, plug-ins which present formats designed, or intended for presentation of e-learning primarily, also and see if any specifically distinct standards make sense.
  • This is a good example of where stepping outside the classic PC GUI model breaks many assumptions of the API-constraints; and is why we need to be extremely careful how we formulate those constraints.
  • Discussed at the January 10th teleconference.

Discussion re-opened on the mailing list

  • Reference to HFES again:
    • Server software (used in client-server and mainframe environments) should be evaluated in conjunction with the client (including terminal) software that will be used with it.
  • Recognition that terminal emulation and remote OS access are not exactly the same thing.
  • Each software component has to be evaluated separately and in and end to end solution. This is not an issue with the technical standard but rather an awareness problem.
  • Character based, dumb terminal user interfaces do not comply with many of the technical standards even when used with emulator software and an AT yet they can usually be used by people with disabilities:
    • They are text-based only and generally consist of non-editable text and editable text. The editable text areas are the input fields. There is no semantic object information to expose.
    • The requirements on color and contrast may not be applicable to the application. Mainframe software doesn't have the concept of a system setting for display preferences. These are all set in the terminal hardware itself and the application can't override those settings. But when the application is accessed via terminal emulation software, the terminal emulation software could utilize the system display preference settings but then it's not "emulating" the hardware anymore.
  • Discussed at May 9th teleconference.

Software vs. Web content

  • The lines between Web content and software are blurring. Some have proposed merging sections 21 and 22 into one category in 508.
  • Analysis and Discussion

Programmatically Determinable

  • Relationship to AT

Subpart A Applicability

  • As a result of our discussion around accessibility requirements for content formats, the following rule for determining applicability was proposed as an addition to the Subpart A applicability section:
    • provisions from subpart B shall be applicable when terms from a characteristic from (reference) are included in the provision language. It is intended that such a match indicates that the specific provision is applicable to such technologies which include such characteristics.
  • Concern that this would require developers to flip back and forth between subpart A and the technical standards
  • Not proposing to remove the "if" clauses from the provisions, just proposing to add this to subpart A.

Authoring Tools

  • Discussion so far has included the following threads & Wiki pages:
    • Wiki page on general need for authoring tool & user agent support
    • (Mostly April) Authoring Tool thread
    • (May 16) Presentation on Authoring Tool Accessibility Guidelines
    • (June 6) Proposal on Authoring Tools
    • (June 12) Proposal (updated) on Authoring Tools
    • Meeting minutes June 13
    • (June 20) Proposal (updated 20 June) on Authoring Tools
    • Meeting minutes June 20
    • (June 27) Proposal (updated 27 June) on Authoring Tools
    • Meeting minutes June 27
    • Discussion between July 25 and August 8 included:
      • Meeting minutes July 25 Conclusions:
        • Remove "author" from definition, and consider removing "publication"
        • For provisions 1, 2, and 4, replace "meets applicable...accessibility standards" with "meets Sec. 508 accessibility standards" (Done)
        • "Interoperability" with evaluation tools needs more discussion on list (Discussion occurred in meeting, changed to "compatible with")
        • Should we change "more than one" to "more than three"? (Discussion in teleconference: No)
    • Discussion thread between July 25 and Aug 8 included... Here are some topical summaries from this thread:
      • We also need to address accessibility of the authoring tools themselves -- mentioned in teleconf & on list that this is already covered by software accessibility provisions. (Addressed.)
      • We don't need any separate guidelines for authoring tools -- as replied on list, authoring tools have a "meta" function in that they create content, and there are a few different accessibility requirements that pertain to them. (Confirm whether sufficiently addressed.)
      • Works better if drop the term "author" -- agreed in teleconference (Agreed to drop.)
      • Might also work better if drop the term "publish" -- but this might create other problems -- discuss best solution on 8 August? (Discussion in teleconference: Need to keep this.)
      • concerns about "interoperability" -- what about "interactively edit"? (Discussion in teleconference: changed to "compatible with")
    • Discussion since August 8 is mainly in the following thread:
    • Discussion from Aug 14 meeting Discussion from August 14 Teleconferenceand updated proposal of Aug 15th:
    • Definition of authoring tools: "Authoring Tool: any software used to create or modify content for publication."
      • Proposed clarification for discussion Aug 15: (Note: this is my attempt to capture the status of the discussion so far; if I've missed something, please help out.) If we were to use an inclusive clarification reflecting the language we removed yesterday (e.g., "'any software' is intended to mean 'any software, or collection of software components', we have not solved the problems inherent in a developer potentially needing to provide conformance statements for an entire chain of software components, some of which they might have no control over. If instead we were to use a non-exclusive clarification (e.g., either "'any software' can refer to more than stand-alone authoring products" or "'any software' can refer to multiple software components," -- or better clarification language if someone can propose that), does this clarification help? For instance, does it enable a developer to claim accessibility support in related products that are part of an authoring chain, and a purchaser to be able to determine what useful level of support for production of accessible content would be available from products that they might purchase? Or is this not what people's concerns were? I think it bears having some brief discussion in our August 15 teleconference, but if neither of such clarifications clearly helps the definition, perhaps it is also better to leave this clarification for after the Aug 17 draft, or possibly to just let the definition stand alone. Thoughts?
    • Provisions relating to authoring tool support for production of accessible content:
  1. <CLOSED> For each accessible content format supported, authoring tools must allow the author to produce content, including content derived from programmatic sources, that meets applicable Section 508 provisions.
  2. <CLOSED> Authoring tools must preserve accessibility information necessary to meet applicable Section 508 provisions, unless the user explicitly indicates otherwise. (Note: after Aug 17, write up a rationale that includes an explanation of why "unless the user explicitly indicates otherwise" is necessary, so that the phrase is not lost during later work)
  3. For authoring tools with a user interface, authoring tools must provide a mode which prompts authors to create accessible content. (Note: this is the first half of the re-split provision which we agreed to try. Work OK?)
  4. For authoring tools with a user interface, authoring tools must either provide a mode which assists authors in checking for accessibility problems, or compatability with evaluation tools that provide that function. (Note: this is the second half of the re-split provision which we agreed to try. Work OK?)(Note: after Aug 17, further discuss and write up a rationale explaining what is meant by "compatability with...")
  5. <CLOSED> Authoring tools which provide pre-authored content, or templates to facilitate production of content, must provide at least one version that meets applicable Section 508 provisions.
  • Discussion summary from September 26 is available, and also the remaining issues summary as of September 26. Summary of points discussed:
    • 8.2-D: Evaluation Support: May need to become an advisory provision, but check with evaluation tool experts to see whether Peter's approach might work;
    • 8.2-B: Preserve Accessibility Information: Clarification note accepted; TEITAC draft should add the following: ""The phrase "unless the user explicitly indicates otherwise" is necessary so that the author has the ability to override accessibility information that may be incomplete or inadequate."
    • 8.2-C: Prompts: Agreed that it needs a clarification note.
    • Definition of authoring tools: Agreed further work needed; see new proposals based on small group discussion over the week following the Sept 26 meeting.

Immersive Virtual Environments (IVE) (e.g., Second Life)

  • Questions have arisen about how we should handle environments such as Second Life, in which users use "avatars" and explore a virtual environment that requires vision, speech, manipulation, and other senses to get the full experience. (See TEITAC Resources for more information about Second Life.)
    • Do the draft standards adequately cover immersive virtual environments such as Second Life?
    • If not, what can and should we add to address it?
  • August 8, 2007, Discussion Plan:
    • Brief Introduction to Immersive Virtual Environments such as Second Life
      • Who is using them and how
      • What do these environments include and how do users interact with them
    • Barriers to Accessibility
    • Discussions of Possible Solutions and Efforts
    • Where do our draft standards fall short in addressing IVEs and Second Life?

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