This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information. Much of the content of this wiki is being migrated to the WCAG wiki at W3C.

From WCAGWiki

Accessibility Support Database Description

The accessibility support database is a place to collect and record data regarding the level of support for features of different technologies by assistive technologies and access features in user agents. The database is organized by technology (e.g. HTML, CSS, etc) and it documents which assistive technologies (or access features) work with which features in a technology (e.g HTML, CSS etc).

Each technology has a page that lists ways to use the different features of the technology to provide information or functionality important to accessibility. For example "ALT on image used as a text alternative". If a feature can be used in different ways to facilitate access then each different type use would be on a different line. (e.g. "ALT on IMG used as a text alternative", "ALT on AREA used as a text alternative".

All of the technology specific sufficient techniques that require accessibility support to be effective should appear in the list of uses, either on their own line or as a series of uses. Some sufficient techniques involve use of multiple features of a technology that would need to be supported, such as those for SC 1.3.1 "Info and Relationships".

Techniques that are not sufficient may also be listed. Some techniques are listed as advisory because they is not any accessibility support today, but may become sufficient when there is enough support.

Accessibility Support Database Prototype Walkthrough

Please review the revamped version of the accessibility support database tool.

From the home page, select the link "conducting a basic search." The Basic Search page contains combo boxes for the different possible dimensions of a technology platform. These combinations include include the host operating system, the web browser, plugins and assistive technologies that a user may be using in combination with one another to access to the Web and are referred to as "permutations" within the site. Select the settings you are interested in and press "Submit Search" to see that slice of the data. For this explanation, use the default settings.

Note: Technology combinations (permutations) includes a list of permutations that the tool is currently configured to accept results for.

The search results page contains an array of "Uses" of technologies.

Each row shows:

• the name of the technology use
• the number of testers who have indicated that this use is supported on this permutation (i.e., it passes the test)
• the number of testers who have indicated that this use is not supported on this platform (i.e., it fails the test)
• the number of testers who have indicated that this use is partially supported on this platform (i.e., it partially fails the test)
• usage notes to provide notes or clarification about the use
• assistive technology (AT) notes (ex. only supported in screenreader X when preference XYZ is set)
• a link to the test page for the use

The use name is a link that takes you to detailed information about the technology use. In addition to the summary data provided on the search results page, it includes notes and additional information about the test results that users have submitted for that use.

The test pages contain instructions for what to do to run the test, the code (inline in the case of some HTML uses, otherwise a link to a test file), and an explanation of the results testers should get if the test passes. If you open this page in the specified browser using the specified AT, you should be able to determine whether the test passes or not.

When a user submits a test result, it goes into a "sandbox" for review. Users can revisit the test page and update their results at any time, but if their previously submitted results have already been approved, their submission is returned to the sandbox for review.

Users can register for an account and log in to the tool when their account has been activated.

• Level 1: Registered users can submit test results.
• Level 2: Can submit test results and view the pending entries in the sandbox, but can not vote.
• Level 3: Can submit test results, view the sandbox, vote for entris and add technology uses. (editor role)
• Level 4: Admin user. Can add technology permutations, manage users, etc. (administrator role)

If logged in with editor permissions, the search results page will contain an additional edit column that links to a page where you can edit information related to that use. For uses that require more complex tests, an upload form is provided at the end of the edit use page. This form can be used to post .zip files containing the test and supporting files that go with it.

Notes

Accessibility Support Features vs Uses

As per previous discussion on the Accessibility Support, it was found that it was not so much the features of technologies themselves but their "use" in various ways that needs accessibility support. For example, does access technology support the use of "alt" on images, the use of "alt" on image maps, etc.

Although it is a bit of work to create all the rows for a technology, this only needs to be done once with a technology. It can then be used to test against the different combinations of OS/UA/AT.

We have gone over HTML and think that we have the "uses" for HTML features that would need access technology (AT and Access features in user agents) support. Please review these uses by using the search feature of the accessibility support database tool and see if there are any that are known to be missing or are incorrect.

We have populated some of the "uses" (rows) with tests.

What are your comments on this concept?

What are the top-priority platforms (OS/UA/AT combinations) to include?

Our CR Exit requirement is: Accessibility support documentation is available for at least two technologies with at least four platforms (operating system/user agent/assistive technology combinations).

• Proposed starting point for screenreaders:
  1. JAWS 9 (because it's the latest and some percentage of JAWS users pay the yearly maint. cost because it's cheaper than having to buy a new license again)
  2. JAWS 6 (I'm not sure why Chris has 5.1 at the top of his list, but I'd suggest 6 given the data he sent from RBM.
  3. Window Eyes 6.0 (I think we can skip 7 for now since it's still in beta)
  4. Orca (latest version, part of GNOME)
  5. VoiceOver (latest version of Mac screenreader)
  6. SAToGo or NVDA or Firevox (These are open-source solutions. If we can find willing testers, it would be good include at least one of them, perhaps more than one if we can find testers who are willing to do the work.)
• Proposed starting point for magnification:
  1. ZoomText
  2. Mac OS magnification features
  3. Windows XP magnifcation features
  4. Orca (listed above under screen readers) is also a magnifier
• Mainstream Browsers
  1. Firefox 2
  2. Firefox 3
  3. Internet Explorer 6
  4. Internet Explorer 7
  5. Safari

Note: With the exception of item 6 in the screenreader list above, all of these are already in the database. There are nearly 60 "permutations" (combinations of technology, OS, Browser and AT) in the database where test results can be submitted. The tool is set up so that it will only accept test results for specified combinations.

Regarding version numbers, it would be helpful if we could adopt a policy about major version numbers that allowed us to collapse, for example, all 2.xxx versions into one AT or UA. The rule of thumb would be something that indicates that testing for a given major version number (ex. 2.0, 3.0) assumes the most recently available version in the series. This would eliminate the need to try to do testing for all the minor variations (ex. XP Professional 5.1.2600 SP3 Build 2600, Firefox 2.0.0.14, IE 7.05730.11, JAWS 9.0488U, etc.). Where changes in support occur, we can indicate that in the function or AT notes fields (ex. "this feature was not supported in versions prior to 2.0.0.12"). From an AT perspective, the model is often that any version X.xxx update is a free upgrade, so collapsing in this way should not create confusion about support from an end user perspective as long as we're clear about how version numbers are handled. This kind of approach would greatly simplify the testing process. Does this approach sound reasonable?

Resources to create tests, run tests, etc.

We need commitments for help from the WG, testing TF, etc.

How to identify uses where different results are expected based on different or no AT?

Supported/not supported may not be easy to make sense of for some uses when no AT is involved (ex. is the alt attribute accessibility supported on Windows with FF2 and no AT?) One possible solution is to handle this in UA or AT notes (ex. add notes related to most CSS uses and their tests indicating that results are not be relevant for screen readers.)