Thread Subject: FW: Subpart A- Draft - Comparable AccessDefinition

Note

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

From: Baker, Robert C.
Date: Fri, Mar 16 2007 12:20 PM

The very first line of the Section 508 Standards states:



Subpart A -- General

§ 1194.1 Purpose.

The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.



This statement makes it very clear that the intent of the Section 508 standards is to provide people with disabilities access to the use of information and data that is comparable to the access available to non-disabled people with disabilities. The FAQs made available on the Section508.GOV site provide the further clarification:



B.2. "Comparable access"

i. What must an agency do to ensure its acquisitions of EIT provide "comparable access"?

Unless an exception applies, an agency's obligation to provide comparable access under section 508 is satisfied by acquiring EIT that meets the applicable technical provisions in Subparts B, C, and D of the Access Board's standards, either directly or through equivalent facilitation (see section B.3, below). Comparable access is not required if it would impose an undue burden on the agency. (See sections B.6 and G.6, below.)





Presumably, the authors of both this FAQ assumed that technical compliance with subparts B,C and D would be sufficient to deliver a "baseline" level of accessibility that would achieve the original comparable access goal. Unfortunately - our actual experience with implementing these provisions has proved otherwise. We have seen first hand many products that while they technically "conformed" to the 508 standards, they implemented their accessibility features in such a way as to make it practically impossible for a person with disabilities to actually use their application in a comparable manner to someone who does not have a disability. The most blatant example is providing a navigation path that requires 30 keystrokes to achieve the equivalent of one mouse click. Has anyone tried using Yahoo with a screen reader lately?



Here are some examples what what SSA has come across:



Screen Navigation



Minimum Keystroke target: At SSA, we emphasize to our internal development teams that functions used commonly in an application (e.g., Save, Back, Next, Cancel, etc...) should be reachable by keyboard through a minimum number of keystrokes. We also emphasize that for a search feature, the user should have a minimum number of keystrokes to get to the search box, move to results, and to page back and forth between the results.



Web Forms



Instructional Text: If you look at 508 strictly you could say that as long the instructional text is "physically" on the screen that is accessible. SSA has placed an emphasis on allowing the user to move through that text "productively" with the keyboard as opposed to being forced to listen to the entire form (and basically memorizing it on the initial read-through or, in the case of a low-vision user, perhaps missing it entirely).



Help Text: Example text alongside form controls - e.g. SSN: {form control} (fill in like ###-##-####) - can bring about a similar problem. The general focus in 508 from a coding standpoint is that the label (e.g., SSN) should be tied to the form control, obviously - however - not having the example text read can be problematic. Once again this is forcing the blind user to listen to the form initially or find out when they get an error back (not optimal from a productivity standpoint).



Data Tables



Visual Summary: 508's focus is on code that ties the data cells to header cells - which is great for a detailed analysis. But many visual users tend to look at a data table to get an overall snapshot of what the data is saying overall in helping them make a decision. From a productivity standpoint you can see how this could have a negative impact for the disabled user seeing as they'd always be forced to work through a data table (as opposed to say having a textual summary that provides an overall snapshot of the table).



Script elements



Dynamic menus: it is possible to make the elements accessible to the assistive technology (e.g., keyboard access, readable) which is what 508 asks for. But a number of times the functionality of being able to expand/collapse menus and move between sub-menus is lost, thus, hindering their productivity.





Unless you are in the business of trying to implement accessible technology with real disabled users - the subtlety of these distinctions can easily be lost. It is not lost at SSA - which currently employees over 1,500 employees with disabilities, and through its e-GOV initiatives - makes available its benefit services to a significant number of Americans with disabilities. Far beyond dealing with individual 504 accommodation issues - if an Agency like SSA rolls out a product that is "technically" compliant with the applicable provisions in subparts B,C & D, but that product achieves this compliance in a way that is not truly comparable to the access available to non-disabled employees, significant employment barriers can quickly be raised. SSA, like many agencies, must always do more with less - which means placing a greater emphasis on using technology to make employees more productive. Employees who are not provided comparable access will not be as productive.



The results can be troubling and disconcerting. Employees with disabilities who are not provided tools which enable them to match or at least come close to matching the productivity of their non-disabled peers can get looked over for promotions, have their work responsibilities curtailed, and possibly even have their entire job taken away from them in exchange for another "less demanding position". Moreover - mangers who would normally consider hiring people with disabilities may take into consideration the accessibility of their work environment, leading many to make discriminatory hiring decisions. At SSA, we are extremely diligent in trying to ensure these scenarios do not become reality. However - a lack of appreciation for this issue in the standards and in the vendor community sometimes makes it difficult to make the right decisions to ensure that discrimination does not occur.



While these issues may be difficult to quantify in a legal statute - we have to ask ourselves why the 508 standards even matter if they can be implemented in a way that does not achieve the original purpose of the law - to provide access to and use of information and data that is comparable to the access and use by people who do not have disabilities.



Therefore, I agree with Deborah that some attempt at creating a definition for comparable access is needed.

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