April 1, 2008
First, the Trace Center would like to thank the Access Board for the opportunity to participate in the committee and commend the Chairs for the job done in organizing and bringing us through. We would also like to commend the committee members for the time, effort and cooperation that was extended in working through what has become a more difficult task in a more complex world. There were differences in opinion, sometimes sharp differences, but the committee never lost itself or broke down and an amazing amount of education occurred for all and better provision language resulted. The provisions are often longer but the length allowed them to be both clearer and to provide more options.
Again a special thanks to the Chairs who devoted an incredible amount of time to this.
Convergence has definitely made things more difficult – but it is a fact of life and one of the primary causes for the update. The world has changed and we need to have guidelines that are based on function so that simple products need only follow rules for their function – but multifunction products can also be easily evaluated.
There is a feeling that we have more provision than before and we do – some. Checking through though it was surprising to find that there were only about 15 new provisions (other than authoring tools, support and agency rules), almost all were in section 3, and 10 of them dealt with cognitive aspects. This was a quick count and more information will be available but most of the proliferation may be from products taking on more characteristics. A look at this is probably warranted.
Harmonization was one of the key goals of the group. Much effort was made to harmonize with both ISO 9241-171 for software and WCAG 2.0 for Web content. Also central was an effort to harmonize between 255 and 508. With the extensive convergence it is important that the developer of such products not have one set of regulations to follow for one aspect of the product and another for another – especially since they share the same hardware and much of the same software. In comparing the two sets of federal regulations (cfr and cfr ) it was surprising how much they had in common even though organized quite differently.
The Access Board is encouraged to maintain the harmonization (or enhance it) as much as possible to simplify the efforts of companies creating products that may have to meet these other provisions as well. As pointed out by our Japanese colleagues, harmonization does not have to mean being identical (though that helps). But it does mean not having provision that are mutually exclusive.
There were two large issues that affected multiple provisions that the committee was not able to come to a resolution on. One of these was the question of AT-IT interoperability. Actually the issues wasn’t AT-IT interoperability which everyone agreed was critically important. Rather it was the question of what constituted AT compatibility and what should be required in order for a product (that was not directly accessible) to pass 508 using AT to provide the access.
“Should a product pass the 508 regulations if it is not directly usable by people with disabilities and if there is also no AT that users can get that will work with it?”
unfortunately gets morphed into
“Does a company have to guarantee that AT will work with their product?”
This is a difficult question because AT changes and often AT has trouble keeping up with E&IT. This is a serious problem and the government and private sector both need to look at what can be done to help AT keep up. The alternative is either we slow down E&IT (which isn’t going to happen), or those who depend on AT will fall behind or fall off. These are our options today and none are acceptable.
Great care will be needed to craft provisions that are realistic for industry and the purchasing system – yet will result in the products being purchased under 508 being actually usable by real people with AT that they can really get.
Tremendous progress has been made and bridges built between the AT and IT industries because of the past requirements that E&IT (that is not directly accessible) be in some way demonstrably accessible via AT. Prior to 508 induced requirements that industry provide some assurance of AT compatibility, the AT industry had great difficulty getting E&IT industry’s attention or cooperation. It is important that the need for AT work with IT not be lost – or this critical link will be lost. At the same time – it must be noted that the AT industry has had difficulty meeting the collaboration demands/needs of all the E&IT vendors. Simply saying that E&IT vendors need to make products work with AT if the capacity is not there will cause great push-back.
We believe the goal must be something that will recognize and promote products that do in fact provide direct access or work with AT that employees and the public can get (the purpose of 508) while at the same time creating some better mechanisms to account for the mismatch in E&IT needs and AT manufacture capabilities.
The development of better APIs is one way to address this – and federal (and private) assistance in developing better APIs is highly encouraged. Good APIs can reduce the load of AT manufacturers and provide a more stable (and less diverse) interface to AT for E&IT manufacturers.
It should be noted at the present time however that there are few APIs that are defined clearly enough that AT compatibility can be assured by simply building to the API from either side. There are a few places like USB-keyboard interface that AT can reliably work with. But complex APIs such as are needed for screen readers have not been shown to be sufficient without testing and often other information.
The working group did some tremendously good work, building on both ISO 9241-171 and other work of the AT and IT companies, to create a list of requirements for information and functionality that an API should provide. (i.e. provision 3-U). And the Trace Center supports that provision. However that provision is not an API and it is very possible to build products that meet that provision and that will not ever work with any AT. As will be noted in our individual comments, the Center supports that and the other AT-IT interoperability provisions (those that talk about programmatically determinable information) with the understanding that these provisions mean that the information can be used by actual AT and that it is not just “programmatically exposed”.
The easies way to address this would be to simply say that APIs are good enough if AT can work with them. If not then they will not help employees with disabilities do or keep their jobs.
Again, the conflict here is not so much with the underlying concepts but with the details in figuring out how to make it easier for E&IT to work with AT that is “available to or can be obtained by those who need it to access the E&IT for work or access to public information”.
The AT issue may be best handled in the pre-amble using text something along these lines:
In this standard, some provisions require products to work with assistive technologies. In order for products and assistive technologies to work together it is (except for certain very well defined interconnections) necessary for both sides to work together. Sometimes assistive technology vendors do not have the capacity to work with every product vendor, even if the product vendor provides incentives or covers some or all of the cost. In these cases it may not be possible for a vendor to guarantee or even achieve full compatibility with those assistive technologies. It is recommended that procurement policies take this into account and make provision for product purchases while still keeping in mind the fact that products that will not work with assistive technologies in substantive ways will not be usable in substantive ways by employees with disabilities or members of the public.
As mentioned above, there are some very well defined interconnections where compatibility with a test tool has been proven to be sufficient to guarantee that products will work with assistive technologies. Where APIs or other standard interconnections exist that have been proven to be sufficient to guarantee compatibility with existing assistive technologies, then passing the test should be admissible as compatibility with those assistive technologies that the tool is certified for. Some mechanism might be used to identify any tools that are developed for this purpose and proven to be effective.
One of they key areas that the group did not reach consensus on was the role of the Functional Performance criteria. In large part, the group deferred to the previous interpretation of the FPC. The group could not decide on what that was however. And the preamble to the older 508 provisions seemed in conflict with the FAQ.
The result was that the committee passed it back up to the Access Board to decide if the functional performance criteria CAN be used or MUST be used in addition to the technical requirements.
The Trace Center, looking at the law, sees that the Access Board is required to provide “technical and functional performance criteria”. Provision that “can” be applied would not be provisions (normative) but rather advisory (informative) in nature and would not meet the definition of criteria.
More to the point however, the FPC are essential to the operation of the standards. In the old 508 standards for example, it was possible to create a touch screen desk phones and pass all of the technical provisions that applied to telephones.
The FAQ stated that “if the technical provisions cover all aspects needed to provide access to the product “ then they were sufficient. The Trace Center believes that the FPC have a role in determining IF “ the technical provisions cover all aspects needed to provide access to the product” and that there is in fact no other known way to do this except to apply the FPC.
For example, there are no provisions in the new TEITAC version that cover free space gestures. However there are multiple products already on the market that use gestures (from games to phones to information processing devices) and additional ones soon to come that will use gestures as a primary input. No specific (technical) provisions were added for this because we do not have enough experience to do so non-restrictively.
The Trace Center therefore recommends that the FAQ language be used (that is – if the technical criteria allow the product to meet the FPC, no additional or other methods should be deemed to be required under the FPC. However, if the FPC cannot be met by meeting the technical, (i.e. the technical are all met but the product still cannot meet the FPC), then clearly the technical provisions do not cover all functionality to provide access.
The Trace Center therefore recommends that the role of the FPC use the word must (in roles 1 and 2 but not 3) since it is the only way that the FPC can be effective – and the only way they can be ‘criteria’ as required by the law.
The purpose of the Functional Performance Criteria is to help Federal departments or agencies determine whether products being used, developed, procured or maintained meet the functional needs of individuals with disabilities. The functional performance criteria have three roles:
- If any of the technical provisions are not met, the Functional Performance Criteria must/can be used to see if access is provided in another way (i.e., through equivalent facilitation.)
- If the technical provisions are met, the Functional Performance Criteria must/can be used to see if the technical provisions cover all aspects needed to provide access to the product. (i.e overall evaluation.)
- The Functional Performance Criteria can also be used to help departments and agencies identify and report product functions that may not meet the Functional Performance Criteria and evaluate the importance of the lack of access to those functions relative to the intended use of the product.
The old FPC had definite testability problems. Terms like “limited reach” and “enhanced audio” were not clear or defined. The revised FPC (that we have consensus on) are all now testable. Discussions with testing experts including NIST confirmed this.
There was one of the original FPC (E – With Limited Hearing ) that the group did not reach consensus on. New testable language was proposed. But some wanted the older more general (and untestable) language. The Trace Center urges the use of the new testable language so as to keep the full FPC testable and usable.
E – With Limited Hearing (Version 3)
Where audio information is required for the use of a product, the product must provide at least one mode that allows user control of volume and/or reduction of background noise. (See note on functional performance criteria and assistive technology.)
Very late in the process the topic of whether section 3 covered hardware or not was raised. This left little time to discuss – and the result is an ambiguous statement in our report. It seems some people were assuming it did while others not – and there was no time to sort it out at the end. So it passes to the Access Board.
The Trace Center understood that section 2 applied to the hardware aspects of a product and that section 3 applied to the behavior which is controlled by the software (including firmware) in the product. If section 3 was not to apply to anything but stand alone software (i.e. it did not apply to products that included hardware) then hardware products would not have to
In listening to the concerns on our phone call, however, they seemed to be centered around problems in meeting the provisions using monitors. This is a problem since many of the section 3 provisions talk about AT compatibility. AT compatibility would be optional if the product was closed and provided built in accessibility it is unclear what that would mean for a monitor. Some things like a sufficient contrast and readable text are reasonable. But it isn’t clear why the monitor would need to be used without vision.
We think this might be related to the ‘accessory’ problem below and suggest that this be examined carefully in light of that issue.
There is a need to cover accessories in the guidelines or application notes. We think the best way is to define them as not being E&IT but rather components. For example, headphones cannot meet most of the provisions if purchased alone. Neither can a mouse. They are just an accessory to E&IT. On the other hand the main CPU could also be argued to be just a component but that would not make sense. We believe that a reasonably bright line can be drawn and one is needed. An attempt might look like:
Accessories are not E&IT in and of themselves and are not subject to these provisions except as specifically noted. To qualify as an accessory, the item must not be able to carry out E&IT functions by itself (either independently or independently after having received data or a command). Mice, headphones and displays are accessories. They only work during the period they are under direct control of another CPU. Printers, are not accessories since they independently carry out E&IT activities after having been instructed to do so.
Interestingly the functions of the monitor dealing with adjustments – can be done while not connected. So making them visual may still be covered
More work is needed here but the issue is included to provide exposure and stimulate discussion.
The text in the report makes this sounds like the group generally agreed on this provision but just could not agree on the language. This is not the intent. The group agreed that there should be some way of handling things like calculators electronic dictionaries, and audio recorders.
However the use of an exception with terms like “narrow delineated use” was felt to be very dangerous. Even in the committee many expanded this to all cell phones even after it was explained that some agencies require a specific phone in order to do push applications – so users were not able to get a different one that met their needs.
An exception for small things that are inexpensive and are never part of a larger system might be in order. But it would have to only use clearly defined terms to avoid becoming a loophole that would be abused. The ability to easily purchase the product was also a concern.
Inexpensive, interchangeable devices
Products that can be purchased from general agency supplies budget (such as calculators, electronic dictionaries, and audio recorders) and that are never part of a larger system (e.g. not used for messaging, data display etc) for which an agency can document specialized products in the commercial marketplace that collectively meet the functional performance criteria (e.g.,have features such as speech output available on one unit, large visual display available on another, large keys/buttons available on another, etc.) and that are readily available and purchasable as supplies are not required to comply with this part as a whole. Agencies must however provide specialized products with appropriate access features as necessary to meet the needs of end-users with disabilities.
The definition of this term is essential to the vast majority of the AT compatibility provisions. The Trace Center notes that if ‘programmatically determined’ is not defined to mean that the information can be accessed by AT (that employees have or can obtain) then there is no real use for the provisions that use the term.
This term therefore goes back to the earlier discussion about AT. It is suggested that this provision clearly indicate that AT can access it and not just some other software. A version like that used in WCAG is therefore recommended
The question of which AT, how much AT etc is independent and should be handled either in the standard as a whole or outside of the standard. But removing the need to work with actual AT from “AT compatibility” is not appropriate. Version 1 appears to require AT to access it but is worded in such a way that it doesn’t really. When changed to plain language in version 2 it was not acceptable.
This is one where there appears to be a fair amount of agreement but it all came up late and could not be handled. This was especially true since it involved a number of provisions on which consensus had been reached.
The problem is that many of the provision require that information be available in text so that AT could access it. The term text though has a broader meaning in general conversation. There can be text in a picture for example – and that is different. The part that everyone seems to agree on was that most of the time when we say text we mean text that AT could read. Some editing needs to be done to just a couple provisions to make them read ‘text and images of text’ to clear up ambiguity (that term is already used in many). Or a new term for text that AT can read needs to be coined and used everywhere. In WCAG it was determined that that made the provisions unreadable so it chose to use text to mean text that AT could use and ‘images of text’ to mean text rendered in pixels etc.
The other aspect of the discussion was whether the ‘electronically readable’ text needed to be readable by AT or just programmatically exposed. This harkens back to the “does real AT need to access it”. Trace suggests that the text be required to be “programmatically determinable” so that the same degree of AT access be required (however strong or loose) for all of the AT compatibility provisions.
It is not clear why this is in not-consensed. We may have just overlooked it but the definition seems to be a good definition.
We would add ‘captioned telephony’ to the list of uses in the definition since real-time text is required for this FCC sanctioned IP captioned telephony.
This should be removed. The definition of Caption should be sufficient.
The text below is from our WIKI. Because we didn’t actually act on it as a committee – it may have fallen through the cracks – or not qualified for inclusion in the report. It is appended here to capture it for the record.
<Text from a TEITAC working pages (WIKI) begins here>
Collected Material for Assistive Technology and Interoperability
These two notes were proposed, and discussed, but no agreement was reached as to how they would be used
Note on Assistive Technology and E&IT (New-2/26)
This note is proposed by the working group on AT-E&IT
This note addresses the question of when assistive technology (AT) is considered E&IT, and is therefore covered by Section 508.
Assistive technology may or may not meet the definition of E&IT. Assistive technology that provides an adaptive interface to E&IT, and that does not provide E&IT functions itself beyond special access functions, does not meet the definition of E&IT.
- When assistive technology is E&IT, the product shall comply with the provisions of this part.
- When assistive technology is not E&IT, the requirements of this part do not apply (but see 3-New Assistive Technology). For example, a screen reader and an adaptive keyboard are interface adaptations and would not qualify as E&IT. A direct-connect TTY and a large button phone are both stand-alone products that provide E&IT functionality and would qualify as E&IT.
- Nothing in this standard shall prevent an assistive technology manufacturer from developing a product designed to provide access for a single disability population.
- Nothing in this standard shall prevent an agency from purchasing assistive technology as an accommodation for an individual with disabilities.
- Nothing in this standard shall prevent an agency from requiring conformance to one or more standards in this part when assistive technology is not E&IT. For example, some AT can be expected to conform to appropriate technical standards and functional performance criteria applicable to the targeted disability population and generally applicable requirements, such as Information, Documentation and Support.
- Assistive technology products that are E&IT, but are narrowly purposed for a discrete disability population, may not conform to all of the technical standards and functional performance criteria using the fundamental alteration exception. However, many can be expected to conform to appropriate technical standards and functional performance criteria applicable to the targeted disability population and generally applicable requirements, such as Information, Documentation and Support.
(Second note is redundant with my previous comments here and it not included)