Peter Korn, Michele Budris, Pierce Crowell
April 1, 2008
Sun Microsystems, Inc appreciates the opportunity to give feedback on the TEITAC report. While we were able to participate in the development of the report, there are items we would like to highlight further, and to have included in the material delivered to the Access Board along with the TEITAC report.
The consensus-based process of TEITAC has resulted in a very thorough review of all of the issues involved in E&IT accessibility. Furthermore, the welcomed participation of any interested party into the weekly subcommittee meetings allowed for an unprecedented level of public participation and review. We urge the Access Board to give great weight to those provisions and language in the TEITAC report that achieved consensus from this broad and expert body.
Sun’s comments below contain either specific additional thoughts in favor of provisions that reached consensus, or arguments for or against provisions proposed but which did not reach consensus.
While Sun contributed in many areas of the TEITAC process, one particular area of focus was in that of AT-IT interoperability. Specifically, we recognized that more and more of the accessible E&IT environments are composed of these three key components: an underlying accessible platform, one or more accessible applications, and an assistive technology using information obtained from the platform and apps. This recognition produced the provisions 3-V Accessibility Services, 3-U AT Interoperability, and 3-VV Assistive Technology.
Together these provisions express a preference for design practices where platforms provide a set of underlying accessibility services, applications expose information to AT through those accessibility services, and assistive technology utilize that information to provide an accessible E&IT experience. There were many discussions on whether it is enough for E&IT to expose functional access and information to AT, or whether a product would have to be shown to work with existing AT. Sun contends that both should be the case, and we note that the Functional Performance Criteria require the use of actual AT in those cases where AT used to meet a given FPC.
But we feel that without procurement direction on assistive technology purchases, it will be possible to continue indefinitely providing employees AT that fails to utilize the accessibility information defined by platforms and provided by applications through these accessibility services. The consequences of such AT procurement would be limitations in the number of applications that are made efficiently and productively accessible. Essentially only those few applications that AT especially supported well would result in realizing “access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to the access and use by Federal employees who are not individuals with disabilities” – the core Purpose of Section 508.
Finally, we suggest that these three provisions be re-titled to better clarify that they are the three components of accessibility interoperability for the platform, application, and assistive technology. We propose the following new titles:
3-V Accessibility Services becomes 3-V Provision of Accessibility Services
3-U AT Interoperability becomes 3-U Exposure via Accessibility Services
3-VV Assistive Technology becomes 3-VV Utilization of Accessibility Services
Separately, some have suggested that E&IT wants to “expose and be done” with interoperability with AT. Sun does not believe that programmatic exposure is all that needs to be considered for interoperability. However, we contend that the standards that cite testing with “existing AT” will not effectively address AT compatibility. Whether a product works with specific existing AT should only be an issue when that AT is what is used at a specific agency, and where compatibility with that product (vs. some other) is a business need. Otherwise, procurement should be based on separately ensuring that all three parts – platform, application, and AT – utilized a shared means of interoperability, and that they the procured components do in fact work well together.
At the close of the Purpose text is a note to the Access Board recommending the inclusion of a note describing meaning of the terms “timely access”, “accurate”, “complete”, and “efficient”, and closing with the sentence: “The determination of timely, accurate, complete, and efficient will not be a quantifiable measure.” Sun would like to see this note make it into the final standards so that these terms, and especially their treatment in accessibility determinations, are not misinterpreted to be measurable criteria.
We believe that paragraph (a)(4) in the 508 edition of Application is redundant and potentially confusing to agencies. There is already a General Exception – Fundamental Alteration – for products and services that cannot be made accessible for reasons of technically infeasibility. This paragraph will serve to confuse agencies that items claiming Fundamental Alteration for technical reasons would then have the same documentation requirements that Undue Burden requires under Section 508. Most agencies will not allow an Undue Burden claim without a lengthy process requiring layers of management approval. We believe it would be less confusing and burdensome if this paragraph is removed. Alternately, if this paragraph is maintained, either the Application section or Fundamental Alteration should point out that the documentation requirements for Fundamental Alteration are not the same as Undue Burden.
Sun strongly endorses the additional clarification of the Fundamental Alteration text contained in this report which extends the text of the existing standard (1194.3(e)). In addition to the clarifications in the first numbered item, the text in the second item serves to limit the impact on Assistive Technology that is covered by the Section 508 standards. This text also addresses some of the reservations expressed in the provision 3-VV Assistive Technology, and was proposed at the same time as the 3-VV provision was proposed.
This update to the text contained in the current standard (1194.3(f)) places significant limitations on, and solves the apparent abuse of, an exception based on the “spaces” that an E&IT procurement might be used. At the same time, it preserves the critical exception around the kind of uses that certain devices are designed for. As a further safeguard against potential abuse, this provision makes clear that agencies should procure an accessible remote control to as much of the maintenance and monitoring as can be accomplished without physical presence.
The language in many of the provisions in the current Functional Performance Criteria: “...or support for assistive technology...” has caused significant confusion. It is unclear whether “support for” meant it had to be demonstrated to work with specific and identified assistive technology, or whether exposing information and complete functional access to assistive technology through a published specification would be the preferable approach for the standards.
In the TEITAC report, this text is removed, and in its place the report states in the note titled “Note on functional performance criteria and assistive technology” that assistive technology is often a critical component of an accessible E&IT environment. It also makes clear that agencies should evaluate accessibility of a product on its own or with necessary assistive technology if such technology is needed to fulfill the Functional Performance Criteria.
We recommend that the Access Board consider the parenthetical remark at the end of each Functional Performance Criteria pointing to this note as informational only. We don't believe that the parenthetical remark, or a phrase similar to “directly or through assistive technology”, belongs with each provision in the final Functional Performance Criteria. If a phrase similar to this is inserted into the Functional Performance Criteria, then agencies – and by flow down vendors and contractors – will be required to test products with unidentified and unlimited numbers of assistive technologies. It is simply not possible to create an effective set of Functional Performance Criteria that require compatibility with existing assistive technology which don’t either become too narrow – stifling innovation and competitiveness – or become so broad and costly – resulting in agencies and the market limiting participation. Individual agencies do have the ability to require compatibility with specified assistive technology, as is the practice today at a number of agencies, and the Section 508 standards should focus on the larger goal of broadly improving assistive technology compatibility.
To best address the issue of interoperability with assistive technologies, the Section 508 requirements should, through standards 3-U, 3-V and 3-VV, procure broad platform, application, and assistive technology compatibility. Agencies can, through requirements specific to a procurement, impose compatibility requirements specific to the assistive technology in use within that agency.
Sun supports this edition of the provision. Most of the earlier drafts were broader in scope (based on the assumption that they applied only to traditional telecommunications products, rather than to all E&IT), and unintentionally placed inappropriate burdens on low-level intra-computer and client-server communications. While we strongly recommend that the Access Board given great weight to all provisions that reached consensus by the Committee, we want to particularly call this provision out. Great care should be taken in any changes to this proposed text to ensure that it does not capture communications that have no impact on accessibility.
Provisions in these two sections involved deep and wide-ranging analysis. The Web and Software subcommittee took great care toward ensuring that the recommended provisions were harmonized with ISO 9241-171, WCAG 2.0 (near final), and ATAG. The analysis benefited from meetings open to the public with contributions from many experts. This group of provisions is significantly more detailed and testable than the current standards, and yet they are not prescriptive or limiting in the technology approaches used to achieve the results. They include standards that for the first time clearly enumerate the information needed by assistive technologies, and that address the “application that is also a platform” issues that rise from technologies like web browsers and the Java platform.
We feel that the end result of this work is a set of provisions that sets a formidable but achievable high-water mark for accessibility
We believe that these three provisions are effectively a subset of what is covered in 3-U AT Interoperability. In the case of 3-F, we recognize the desire by other TEITAC members to stress Web-related aspects, for WCAG harmonization, and to specifically highlight CAPTHCA issues, and therefore did not oppose reaching consensus on this provision. In the case of 3-O and 3-P, we recognize the desire by other TEITAC members to achieve WCAG harmonization, however, the overall number of provisions is burdensome and these we feel three provisions can be left out without loss.
We are pleased with the language in this provision that was deliberated at length. One significant desire from some TEITAC members was to require one or two specific real-time text protocols as the standard protocol(s) that must be employed and supported. While such an approach has the allure of potential interoperability between E&IT products that use such a standard, we agree with our industry colleagues that these proposed standards are too untested to be mandated at this time. Further, we feel that the underlying communications technologies are evolving too rapidly to apply a specific protocol to this field. Multiple E&IT vendors are actively building and deploying products in this space, and we believe that the outcome of those deployments will provide us with necessary information about what does and does not work, from which in the future we may be able to make more specific requirements.
The provisions in Subpart D are an important departure from both the rest of the document and from the existing 508 standard. 2-C in particular addresses a critical problem that can arise apart from the formal procurement process – the actual installation and configuration of an E&IT product (and any necessary AT), so that the end result is an accessible E&IT environment for agency employees. Whether the Access Board ultimately decides this provision is in or outside of scope for 508, we strongly urge the Access Board (and if not them, the FAR) to enshrine the principle of an agency responsibility for configuring procured E&IT so that it achieves the goals of 508 – the creation of an accessible E&IT environment.
The Advisory Notes are important for both procurement and E&IT development, but are inappropriate or even harmful if written into the standards themselves. Sun supports all of these notes as written, and feels strongly that remain advisory notes and not become required provisions in the standard.
Sun agrees with the comment from Microsoft that no single Functional Performance Criteria can be crafted to serve such a numerous and diverse group of disabilities. As is noted in Table 2 at the end of the TEITAC Report, there are large number of technical provisions that provide significant benefit to many individuals with cognitive, language, and learning disabilities.
The difficulty is that these criteria cover a very broad spectrum of user needs. The needs of some users are actual in conflict with the needs of others. What helps one user with a cognitive disability can actually make things worse for another user with a different cognitive disability.
It is appropriate to highlight those technical provisions that broadly address this collection of disabilities/limitations but it appears too early and practically difficult to craft Functional Performance Criteria to serve the current Section 255 and 508 standards refresh.
We believe that significant additional research into the best techniques for meetings the needs of these populations is needed. In situations where user accessibility needs may be in conflict, the best solution is to provide access through the use of an assistive technology. With little to no AT in this space, meeting such a Fundamental Performance Criteria is impossible, with little sense of when that might change.
Sun feels that this provision is not only unnecessary, but is potentially harmful to the technical standards.
The Graphical User Interface (GUI) as it has developed over the last several decades is a profoundly visual experience. By contrast, the GUI overall is very little developed as an auditor or tactile interface. As the E&IT industry has developed a very rich "visual landscape", the bulk of the technical standards that reached consensus in one way or another address very specific technical aspects of making this "visual landscape" accessible.
Reprising the dozens of technical standards that cover the rich visual landscape of making the GUI accessible in what would be a redundant 1-E Visual Information provision not only introduces an additional provision where none is needed, but it calls into question whether meeting the other visual technical standards is sufficient or not. It does this in part through the phrase (added emphasis) “all information that is needed for operation that is provided visually…”, calling into question with the many other visually-related provision cover “all” or just “some” or “most”. Finally, the specific non-visual means suggested result in preferring access by some people with certain disabilities over other people with different disabilities. Contrast this with the only slightly more general Functional Performance Criteria A - Without Vision that suggest no such preferential treatment of certain disabilities over others.
A provision covering text size is needed. There was a great deal of discussion and negotiation surrounding this proposed provision, but one thing made clear – despite the technical issues raised with all the various methods – was that a text size provision that easily lends itself to simple testing was supported by the Committee. We just could not find the methods or wording that would satisfy all parties, situations, or product types. It is unfortunate that this task is being handed off to the Access Board without a provision that reached consensus from the Committee. It should be noted Sun did not witness disagreement on the need for a text size provision.
Sun appreciates the importance of clearly indicating keyboard shortcuts for a variety of users, including users of assistive technologies like screen readers, and users with a variety of cognitive, language, and learning limitations. In our experience most software applications for the major desktop environments already does a good job of providing clear visual indication of keyboard shortcuts. We note that where this visual indication is made, it is subject to Functional Performance Criteria B - With Limited Vision, which means that any visual indication of keyboard shortcuts must be visible to individuals with limited vision.
We believe international harmonization is important, and we agree with IBM's comment. Making 3-SS a formal requirement would create a U.S.-unique requirement, which we feel is a poor precedent. We feel that 3-SS version 2 should become a strongly worded advisory note, and be added to an Advisory Notes section of a final standard.
This provision, along with 3-V Accessibility Services and 3-VV Assistive Technology, are vital to address and improve the compatibility assistive technologies. While 3-U AT Interoperability is marked only as “partial consensus” in the report, this is due to the late addition of a single clause to address the programmatic exposure of keyboard shortcuts and implicit designators (as part of discussions around 3-SS Visual Indication of Keyboard Shortcuts that also did not reach consensus). The rest of this provision was the result of careful, inclusive, and deliberate discussions between a broad array of E&IT and AT developers and disability advocates. This provision was derived from the set of accessibility services provided by the proven accessibility frameworks of the Java platform, the UNIX platform, Macintosh OS X, and the IAccessible2 interface on Windows. All of these enable a collection of sophisticated and powerful assistive technologies that exclusively rely on these platform accessibility services to achieve very efficient and productive user environments for people with disabilities.
Criticisms surrounding the proposed language for and late addition of 1-g are legitimate. Item 1-g should either be removed, or retained but improved to address insightful concerns.
While 3-U can stand alone, it influences market conditions and benefits agencies best when combined with 3-V and 3-VV. Most importantly, the combination of these three recommended standards addresses the difficult problem of making agency in-house developed applications compatible with assistive technologies. Assistive technology compatibility is best addressed when the underlying platform defines a set of accessibility services so that each application need not invent its own way of exposing information and functional access to assistive technologies. When 3-U is combined with 3-V, we greatly increase the likelihood that applications will utilize the set of accessibility services already defined by that platform, while still allowing applications and assistive technologies to utilize other techniques for interoperability.
Sun feels strongly that this is an important provision that should be adopted by the Access Board. The technical standards enumerate the specific aspects of technology that procurement agents should ensure are present before procuring E&IT. In order to provide for an accessible E&IT environment for federal employees with disabilities, it is generally the case that three distinct components must be present and working well together. Those three components are:
With 3-U AT Interoperability and 3-V Accessibility Services we have specified the necessary aspects for procurement of two of these three key pieces for interoperability. In 3-V we have made it clear that agencies should procure only those platforms that define a set of accessibility services for applications to use to interoperate with assistive technologies. Without this, applications have no standard, platform-wide mechanism for such communication, which has led to the current problem of assistive technologies used in the Federal Government working well only with a relatively small number of applications. Applications outside of this small set often don't work as well with these assistive technologies, if at all.
Unlike most other provisions where we failed to reach consensus, here it wasn’t because the text came too late in the process. Rather, the failure came from a philosophical difference of opinion on the importance and value of such a provision. Since the text was proposed several months ago, there have been no proposed changes to it.
Sun recognizes that procurement of assistive technology may be done as part of a Section 504 Reasonable Accommodation. But after such procurement and deployment of assistive technology occurs, additional software applications are procured and installed, and those new E&IT procurements may or may not work with the procured AT. If the procured AT is operating in the model of “special-case” and “reverse engineer to provide access”, then it will only work well with those applications it was specifically designed for. This will almost certainly not be the majority of applications on the market, let alone those developed in-house by individual agencies.
We fully agree with ATIA that programmatic exposure of functional access and information to assistive technologies via platform accessibility services, in combination with AT use of these accessibility services, is not a guarantee that there will be no interoperability problems. Nor is it a guarantee that the three pieces used together (platform, application, and AT) will be efficient and productive for all users with a disability. Frankly, no set of technical provisions can make that guarantee. But we will do far better by encouraging interoperability through the use of shared standards and shared accessibility services.
By including 3-VV Assistive Technology, it will be clear to agencies that the best AT to procure is that AT which does it's part toward interoperability: which utilizes the platform accessibility services where appropriate to the AT's function.
Sun agrees with the comments from IBM. Both versions of this provision make the assumption that all products are hardware products, when increasingly software running on general purpose computers, be it desktops or hand-held devices, are used to make calls. The comments from Trace do not address the issue of physical connection to a TTY device.
The purpose of this provision is better served, as is done in the technical provisions, by requiring internal agency templates to meet the Section 508 standards. The main intent of some Committee members is for office automation software to include at least one template of each type that is accessible. Such a requirement would be very problematic for products like Integrated Development Environments (IDE), which include large volumes of templates. Further, many products only supply templates as a convenience – and some provide access to libraries of user-contributed templates – and in these cases no support is given for them. Finally, Sun disagrees that provisions should be written only requiring “one version” of the templates to meet applicable standards. While there was general agreement that it is too costly to make all authoring tool templates accessible, the best solution is to require all internal agency templates to be accessible.
Sun agrees with the comment from IBM.
This definition did not reach consensus but is very important to a number provisions Sun finds vital to a successful refresh of the standards. We believe that version 2, without the second note is the best of the three options for this definition presented. The issue with the second note (of both version 2 and version 3) is that it defines things in terms of what AT might be doing (including the case where AT is reverse engineering an application in order to make it accessible). Such a circumstantial definition – dependant upon some outside action – makes it impossible for an E&IT developer to know on their own whether they have made something programmatically determinable or not.
A further twist to a definition that includes either of the two versions of the second note is that a web page could contain programmatically determinable content when running on one platform (or through one browser), while that same content becomes not programmatically determinable if viewed from a different browser or on a different platform. Fundamentally the proposed language in these two second notes is about trying to find a way to ensure that AT and IT interoperate, which we feel is best done by procuring AT as well as IT that formally meet the three interoperability standards of 3-U, 3-V, and 3-VV.
The definition of Text failed to reach consensus because it was tied to the term “programmatically determinable,” which has issues as noted above. The best approach is to define two terms: 'text' and 'accessible text' (or 'programmatically exposed text' or even 'e-text'). 'Text' would have its usually and broadly accepted meaning, while the other term would carry with it the programmatic determinability notion.
Sun is among the TEITAC members who recommended this definition for consensus. Unfortunately we did not have a quorum, nor sufficient time to discuss it at the end of our deliberations when we did again have a quorum.
Sun supports the definition in version 3.
Sun concurs that the definition should be removed.
Sun feels that the issues being addressed in this proposed exception are significant, and it important to find a way to address them. Part of the accessibility challenges over the past 5 years have come from the convergence of telephony with information technology, and the combination of these two in small (and often inexpensive) consumer devices that by their nature tend to be “personal”. This issue was recognized in a different form in the proposed language for 1-G Text Size, where paragraph (d) recognized a category of “personal devices” that would be exempted from the text size requirements in cases where the agency didn't require a specific device or family of devices to be used, and further where the device wasn't shared.
Sun feels that this concept of “personal devices” should be applied more broadly, with accessibility exemptions likewise applying more broadly. At a minimum, we should allow consideration of an additional exception for Narrow Delineated Use products like calculators, cell phones, PDA, etc. that follows the same logic as is in paragraph (d) of provision 1-G Text Size. There is an exception to prevent the needless installation of software or devises used for accessibility at an individual’s workstation who is not disabled – provision (1194.3(c) – and this provision should be considered equally to extend this practical application to personal devises for individuals without disabilities.