| Working Papers | ||
| Back to Fedstats home page | Topic links - A to Z | Search | ||
The amendment to Section 508 by the Rehabilitation Act Amendments of 1998 requires that when federal departments or agencies develop, procure, maintain, or use Electronic and Information Technology (EIT) they must ensure that the EIT is accessible to federal employees with disabilities. In addition, the amendment requires that the public, disabled or not, have comparable access to and use of information and data from federal departments or agencies. As directed by Section 508, the Access Board set 16 specific standards for "Web-based Intranet and Internet Information and Applications."
After the announcement of these standards, many government agencies and private vendors began to offer technical assistance, training, and software to help determine whether agency Web sites met the Section 508 requirements and to bring the sites into conformance. However, these efforts lacked specific guidance on tables and charts with the level of sophistication needed by the federal statistical agencies.
Frustrated by the lack of guidance and facing a tremendous workload as a result of Section 508, the FedStats Task Force decided to sponsor a workshop on the major issues facing the statistical agencies, stemming from the Section 508 standards for Web-based applications. On June 24, 2002, the FedStats 508/Accessibility Workshop was held. The workshop provided coverage of the Section 508 requirements concerning tables, charts, and mathematical formulas in unprecedented depth. In addition, the workshop brought together representatives from all of the principal federal statistical agencies as well as other government agencies with members from the disabled, research, and vendor communities.
This paper summaries the motivations for and findings of the workshop. It outlines the issues facing the statistical agencies in trying to conform with Section 508 and provides recommendations by sector to help resolve these problems.
Acknowledgements: The authors wish to thank the FedStats Task Force and the FedStats 508/Accessibility Workshop planning committee, Ken Nakata (Department of Justice), and Doug Wakefield (U.S. Access Board) for their helpful comments. Sherry Snyder (Social Security Administration), John Gawalt (National Science Foundation), and Cheryl Roesel (National Science Foundation) provided editorial assistance.
On June 24, 2002, the one-year anniversary of the implementation of Section 508, the FedStats Task Force of the Interagency Council on Statistical Policy held a 508/Accessibility Workshop. The workshop was unique in several respects. First, it provided coverage of selected Section 508 requirements in unprecedented depth from a statistical perspective. Second, the workshop audience included representatives from the full spectrum of groups concerned with Section 508: over 40 different government agencies were represented, along with members from the disabled, research, and vendor communities.
This paper summarizes the motivations for and findings of the workshop and provides a roadmap for future work and research. It lists the issues raised at the workshop, with recommendations for future activities aimed at solving them. One of the primary issues raised was the need for clear, definitive standards for tables. As a result, the FedStats Task Force plans to publish a recommended implementation of Section 508 as it pertains to statistical tables. In addition, many issues require more research. The FedStats Task Force will consider issuing a recommendation for future research on a more robust and flexible attribute scheme to better facilitate the accessibility and usability of tables.
On August 7, 1998, President Clinton signed into law the Rehabilitation Act Amendments of 1998. The amendment to Section 508 requires that when federal departments or agencies develop, procure, maintain, or use Electronic and Information Technology (EIT) they must ensure that the EIT is accessible to federal employees with disabilities. Section 508 also requires that all members of the public, disabled or not, have comparable access to and use of information and data from federal departments or agencies. Section 508 encompasses various means for disseminating information, including computers, software, and electronic office equipment. It applies to, but is not solely focused on, federal pages on the World Wide Web.
Section 508 directed the Architectural and Transportation Barriers Compliance Board (known as the Access Board) to set standards for the various information technologies. On June 25, 2001, the standards set by the Access Board became a part of the Federal Acquisition Regulations (FAR).1
The Access Board outlined 16 specific standards concerning "Web-based Intranet and Internet Information and Applications," drawing on the Web Content Accessibility Guidelines developed by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C).2 Many of these provisions focus on access to computer-based information for people with vision impairments. Such users often rely on assistive devices, such as screen readers, which translate information into automated audible output, and refreshable Braille displays. Certain conventions, such as verbal tags or identification of graphics and format devices, like frames, are necessary so that these assistive technologies can "read" them for the user in a sensible way.
With the issuance of the FAR, federal agencies began to grapple with how they would meet the Section 508 requirements. The Access Board, the General Services Administration, and many others provided technical assistance and training. Vendors began offering software to determine whether agency Web sites met the Section 508 requirements and to bring sites into conformance.
FedStats is the interagency Web portal to statistics produced by agencies of the United States government. It was created at the direction of the Interagency Council on Statistical Policy, which is composed of the 14 principal statistical agencies and headed by the Chief Statistician of the United States. The FedStats Task Force oversees the FedStats Web site and sponsors activities concerning the use of the Internet and related technologies by the statistical agencies. In particular, FedStats focuses on issues common to the statistical agencies that would be better addressed collectively rather than individually.
At a FedStats Task Force meeting early in 2002, a discussion of common issues identified that many agencies were having trouble meeting the Section 508 standards—particularly the requirements that apply to tables and charts. The agencies were frustrated by the lack of guidance on tables and charts and with the level of sophistication that they needed. Examples offered up by various organizations were too simplistic, focused on look-up rather than data tables, and were inconsistent not only across organizations but within organizations as well. These issues also tended to get cursory treatment at the various Section 508 training sessions available to federal agencies. Because of the large volume of tables produced by the statistical agencies, implementing the standards represented a tremendous workload. Agencies needed solutions before investing resources in making their Web sites conform to Section 508.
As a result of this discussion, the task force decided to sponsor a workshop on the major issues facing the statistical agencies, stemming from the Section 508 standards for Web-based applications. The task force designated a planning committee for the workshop. In planning the workshop, the committee was acutely aware of the fact that although management was very focused on meeting the Section 508 requirements, broader issues concerning accessibility and usability extended far beyond the 16 points of Section 508. Therefore, the committee tried to balance the workshop's program in both respects. The initial plans for the workshop included a much broader agenda, but as the depth of the sessions increased, it was necessary to limit their breadth to the core issues unique to the statistical agencies. In the end, tables and charts became the focus of the workshop, with some time spent on mathematical formulas, because of their prevalence in the presentation of statistical research. However, it was felt that this last topic was one that would be tackled by the larger scientific community as well.
The committee also recognized that solutions to the problems faced by agencies would require the attention of the disabled, research, and vendor communities in addition to the government. All of these groups, working in concert, were needed to help agencies resolve the problems they were facing and to advance how accessibility will be dealt with in the future.
On June 24, 2002, the one-year anniversary of the implementation of Section 508, the FedStats Task Force held its 508/Accessibility Workshop.3 The workshop provided coverage of the Section 508 requirements concerning tables, charts, and mathematical formulas. Over 150 people attended the workshop, including representatives from all of the principal federal statistical agencies as well as many other government agencies. In addition, members from the disabled, research, and vendor communities were represented.
Tables of numbers are the primary product of the statistical agencies, and they produce those tables in vast quantities. For example, the annual Statistical Abstract of the United States alone contains over 1,900 tables—that is just a single publication in a given year. Multiply that by the number of statistical agencies, the number of publications produced by each of those agencies, and the various frequency with which those documents are produced—daily, weekly, monthly, annually—and the number of tables quickly soars into the thousands, if not the millions. Statistical tables are often quite large and complex, displaying many concepts and measures as well as appropriate metadata. From years of experience in disseminating tables in print, agencies have developed fairly standardized presentation methods to make statistical tables easier to read and understand.
Until the mid-1990s, printed documents were the primary medium for publishing statistical data. Even now many tables are formatted using a Government Printing Office style created in the 1940s to allow typesetters to easily align numbers for printing.
Then the proliferation of desktop computers changed tables in two important ways. First, the advent of desktop publishing meant that agencies could start moving away from a style driven by the demands of typesetting and could instead focus on presenting their data in a way based more on human visual perception and better utilize the inherent patterns present in the data. Second, the development of computational tools moved numbers into a different realm—spreadsheets that maintained the computational properties of the numbers became a common, and often desired, publishing format.
Although the technology has changed substantially over the past few decades, the overall production process has not experienced a similar evolution. For many agencies, production still ultimately requires putting ink to an 8½″ × 11″ sheet of paper. As a result, the basic structures and file formats for tables are still based on the production of a printed document.
Recently, with the advent of the Internet as a viable means of dissemination, statistical agencies have begun presenting their tables in a variety of electronic formats, such as those described below.
ASCII Text. This was one of the earliest electronic formats agencies used to disseminate their tables. Based on original computer output, text tables rely on spaces or tabs to create their formatting. This raw-text output has been published directly for many years by federal agencies and has also been used as input for desktop publishing systems. ASCII text can be easily embedded in Web pages by simply enclosing the formatted output in a pair of <pre> tags. Although they present data in visually ordered columns and rows, ASCII text tables lack a true table structure.
Portable Document Format (PDF). The first new solution in moving to electronic distribution was provided by Adobe Systems, Inc., with the Portable Document Format (PDF). That format allowed agencies to create electronic replicas of their paper documents that could be viewed on most platforms using the free Adobe Reader®. This solution was widely adopted because of its ease of implementation as part of the printing process and the similarity of its output to the agency's printed product. However, the underlying structure of data tables is not maintained. For example, when using the free reader, data that are copied from a table in a PDF file and pasted into a spreadsheet are not automatically placed into individual cells so that they may be further analyzed and manipulated. In addition, the order of the data is scrambled so that the data cannot be parsed into a proper table.
Spreadsheets. Because of the computational properties of numbers, many statistical agencies have been preparing and disseminating data in spreadsheets. Before the Internet, these spreadsheets were used in the desktop publishing process and distributed on diskette or
Hypertext Markup Language (HTML). HTML is a tagged based language that forms the basis for most Web pages. It includes a suite of tags for formatting tables. Although meant for use with data tables, these table tags are also often used for page layout, because of deficiencies in early versions of HTML.
Early ventures into HTML frequently required that tables be coded by hand—not a small undertaking. In the simplest HTML tables, a pair of <tr> tags defines each row, and pairs of <th> or <td> tags define cells within that row and indicate the cell's role as a header or data. For example, a row in a table with a row stub and two pieces of data would be coded as follows:
<tr> <th>States</th> <td>42</td> <td>8</td> </tr>However, additional tags and attributes are often included. Therefore, even a small, simple table results in many lines of code.
Improved tools to prepare HTML tables, including conversion modules built into desktop publishing packages, have eased the task somewhat; consequently, more and more tables are being presented in this format. However, many of these conversion algorithms produce invalid HTML that often includes proprietary tags, requiring that the files still be finished individually, by hand.
Section 508 requirements for Web presentation of tables are primarily aimed at making the content accessible to the visually impaired, who access computer-based information using various assistive products. This technology is used for accessing not just Web-based information but all computer-based information. Because these products read pages from top to bottom and left to right, any meaning conveyed solely by visual formatting is lost.
As discussed above, ASCII text tables and tables in PDF documents do not inherently maintain the structure of a table. Therefore, assistive devices treat them no differently than lines of text, simply reading them left to right, down the page; the listener cannot associate the numbers with the appropriate labels.4 However, tables in spreadsheets and properly coded HTML that uses the suite of table tags do maintain a column and row structure. Therefore, assistive technologies may leverage this structure to provide more meaningful output.
Two of the 16 Section 508 standards for Web-based applications apply to tables presented in Web formats:
HTML. For HTML tables, the markup required depends on the complexity of the table. Three different levels of markup are included in the HTML 4.01 Specification.
The simplest tables have one level of column headers immediately above the data to which they refer and one level of row stubs to the left of the applicable data (see Figure 1). Because these headers are placed in the same column or row as the data, making the required association is very easy—they simply must be identified as headers, using <th> tags. With the proper tagging, screen readers may render the first row of the table in Figure 1 as "Age,
However, tables with two or more levels of headers pose a greater challenge because the headers do not have a predictable placement relative to the data. For tables that have no more than two levels of column headings or row stubs, these associations may be made by specifying groups of rows or columns to which a header applies. However, such groupings cannot be nested. Therefore, for the most complex tables, those with more than two levels of column headers or row stubs, the relationships must be individually coded into every cell (see Figure 2). Each column and row header is first labeled with a unique identifier using the id attribute. The relevant identifiers are then included in a list and associated with each data cell using the headers attribute. As one would expect, adding id and headers attributes to every cell in a table is not only tedious, but it also significantly increases the file's size.
Spreadsheets. Spreadsheets are often considered to be potentially accessible because the cell address relates to columns and rows, allowing navigation and association; however, complex associations cannot yet be made. Screen readers read cell-to-cell based on how the user navigates. In a simple spreadsheet the labels are at the top of the columns or in the first row (see Figure 3). For example, the labels for data in cell B4 are in cell B1 for the column label and in cell A4 for the row label.
Frequently, tables presented in spreadsheets have additional information in the first several rows, so the user cannot presume in which cell the labels will start. When column labels are entered into more than one cell, or cells are joined to show visual hierarchical relationships, the relationship between the cells involving data and those involving labels is not easily handled by simple navigation.
Summary. With the advent of the Internet, many new means of distributing tables became available to statistical agencies. Some of these methods produced things that looked like tables but did not actually maintain the underlying table structure. However, two methods—HTML and spreadsheets—do maintain the inherent structure of the table. As a result, the structure can be leveraged to associate the data with applicable labels. Although the theory behind making these associations is rather intuitive, the methods for doing so are not clear cut.
Many coding alternatives were presented at the workshop, but the bottom line echoed by all the presenters was to "code to the standard." However, "the standard" is rather sketchy. Both the W3C and the Access Board offer examples of coding, but those examples are not instructive for several reasons:
Many participants at the workshop expressed frustration with the lack of specific directions. They are looking for exact guidance on what is expected as it pertains to the type of material they are dealing with and are not finding definitive answers.
Recommendation: In the absence of any definitive standards, the federal statistical community should develop a recommended implementation for tagging statistical tables for accessibility.
A divide currently exists between what "works" and the standard. The various assistive devices interpret the code in a variety of ways.5 Coding for one device, or one particular version of a device, is likely to result in improper rendering in another tool or in the same tool in the future.
Many agencies use assistive devices to test their coding. Sighted users often obtain screen readers and listen to the results to gauge their conformance with the standards. This practice is problematic in two ways. First, the currently inconsistent aural rendering of content produces inaccurate results—it should not be relied on as a method for verification. Second, as generally novice users of assistive technologies and with no experience of relying solely on aural renderings for information, sighted users lack the appropriate experience and background to make an appropriate judgment of accessibility—an accurate test requires evaluation by an actual user of the assistive device.
Recommendation: In the long run, technology is expected to converge with the standards so that all devices will produce similar results from the same tags. Additionally, creating a recommended implementation, as discussed above, should not only speed this process but also allow the development of more robust validation techniques—eliminating the reliance on testing pages with assistive devices.
Statistical tables are generally produced to allow users to make comparisons between numbers, to find logical visual patterns in the data, or to look up a specific piece of information. The current technology allows visually impaired users to perform only the last task easily. Even if all the statistical tables produced by the federal statistical agencies were properly marked up, it is doubtful that users needing such assistance could use most of them as they were intended. By rendering cells sequentially, assistive devices—particularly screen readers—make it impossible for users to compare cells that are not adjacent. Furthermore, the markup is not extensive enough to describe the often complex relationships among headers (parent and child, siblings, etc.).
Recommendation: Additional research needs to be conducted into how to provide better usability to the visually impaired. New types of assistive technology that rely on senses other than hearing may be needed. Additional markup tags and methods may also be needed, particularly to provide information about the relationships between headers. Additionally, there may be differences in how people who have never had sight and those who were once sighted perceive tabular information. Therefore, their accessibility needs may be very different.
The Internet has expanded the audience for statistical content in ways never dreamed of by the agencies. The traditional audience of the statistical agencies used to be a relatively limited number of subject-matter experts. Now, every home with a computer and a modem can access the tremendous store of information held by the federal statistical system. Instead of being a paradigm of mediated inquiry, the statistical agencies are quickly moving to a self-serve, sometimes customized, delivery system.
Many of the participants at the workshop who were not users of statistical agency products questioned why the agencies needed to produce so many large, complex tables. They wished for simpler, easy to understand tables or alternative presentations.
To facilitate print publishing and minimize costs (of both publishing and mailing), tables are put through many contortions in order to fit as much data and metadata as possible on each page. The results are large, complex data tables, which are now expected by some users and often are responsive to legislative requirements. Only when the original data source or native publishing format was in a convenient electronic form did tables reach the Web. Unfortunately, what works on paper is not necessarily the best way to present information electronically. In an optimal world, agencies would present data in a variety of formats to best fit each medium of distribution, but because of limited resources and customer expectations, that may not be possible.
Recommendation: Research needs to be done on the best methods of presenting numbers electronically to facilitate their intended use, while still meeting any preexisting user expectations or legislative requirements. New publishing paradigms are needed for the Web as the limits of paper are removed. However, the ability to also produce a print product must not be compromised as a result.
Statistical agencies have developed techniques to make tables more usable to sighted users. For example, many use white space to group similar items, to highlight patterns in the data, or make it easier for users to locate particular numbers. However, some screen readers stop when they reach a blank cell.
Metadata is often provided in footnotes to rows, columns, or particular pieces of data. To keep the visual patterns clear, footnotes on data may appear in an adjacent cell. Additionally, notation for the type of measure (%, months, etc.) may appear only with the entries in the first row of a table. However, these techniques often pose problems for screen readers because there is no way to associate such metadata with its respective data.
The extra markup required to make tables accessible results in large files that take a long time to download from the Internet. Lack of speed, including slow download time, is one of the major complaints voiced by Web users. The extra, unnecessary coding that results from conversion tools provided in authoring software compounds this problem. To address this issue, one agency, for example, provides users with text tables embedded in HTML which include a link to an accessible HTML version of the same table.
Recommendation: More tagging options should be provided to instruct assistive devices to skip markup intended for sighted users. This should permit agencies to present tables that are both useful to the sighted as well as accessible. Techniques for associating footnotes and other metadata with data cells also need more development. Additional research needs to be done on how to improve markup without substantially increasing file size.
Today, the statistical agencies are faced with increasing demands:
Visually impaired users who would benefit from the markup required for accessibility make up a relatively small portion of the statistical agencies' customer base. The Census Bureau estimates that in 1997 there were 1.8 million people age 15 or older in the United States who were blind, approximately 0.6 percent of the population.6 In 1994 the National Center for Health Statistics estimated that 517,000 people used some type of vision assistance device, including 59,000 people who used Braille.7 (At the time, the number indicating computer use was too small to produce statistically reliable estimates.) Clearly, many more people with and without disabilities are using computers today. According to Freedom Scientific, "JAWS® for Windows is the world's best selling screen reading software, exceeding 78,000 users worldwide and growing."8
The work needed to properly tag complex tables is considerable. At the time of the workshop, none of the desktop publishing or authoring tools could make the associations needed in order for the HTML translations to be accessible. Markup had to be added through other software, such as a text or HTML editor or an accessibility remediation tool. This work is often done one table at a time and frequently one cell at a time. The Census Bureau estimated that it would take 1½ person-years to properly tag all of the tables in the Statistical Abstract of the United States.9 At the time of the workshop, only a few tools existed to assist agencies in adding this markup. Since then, several vendors have improved their products and added new capabilities, but this new technology has not yet proliferated.
Given the volume of tables produced by the statistical agencies, the costs of conformance are significant. Because the size of the audience and the benefits to other groups are small, the agencies are hard pressed to make a business case to invest what is needed. Therefore, agencies are looking for cost-effective ways to meet the Section 508 mandate. Several agencies presented automated solutions that they had developed.10
Recommendation: Vendors that produce remediation tools and authoring software should focus on how their products can support batch processing and further automation of the tagging. Since the workshop, many vendors have made great strides to improve their products' ability to tag complex tables. It is hoped this trend will continue so that more programs, particularly the authoring tools, will have built-in support for 508 table tagging.
In addition, research needs to be done on how such tagging might also be used to help sighted users. For example, the tags combined with Extensible Markup Language (XML) might be leveraged to assist people searching for data in tables. This approach could facilitate the use of natural-language queries. Such additional benefits would improve the likelihood that agencies would make the needed investments.
Although remediation tools are available that can check for the existence of attributes, they are unable to make any qualitative assessment about those attributes. When markup is added cell by cell, it is very easy to put in an incorrect value for a headers attribute. In addition, many agencies depend on contractors to provide tables with valid markup but have no method for quickly checking the tables submitted—reviewing the code must be done line-by-line, making it a difficult and time-consuming task.
Recommendation: It is hoped the vendor community will provide new software to assist in validating the markup. Since the workshop, some vendors have added this capability to their software. Additional ways for adding associations to the data, as recommended above, could also provide a means for automated validation.
In addition to tables, the federal statistical agencies commonly produce statistical charts and maps. These depict everything from the growth in Gross Domestic Product (GDP) to the proportion of the population in various age groups. Statistical charts are geometric representations of the data that present the big picture, highlight a point, or reveal a relationship not obvious in a table of data. Just as a picture is worth a thousand words, a statistical chart may summarize thousands of data points.
The standards included in Section 508 for the presentation of charts on the Web are also aimed at making the content accessible to the blind. Charts are presented in a variety of graphical formats, which do not naturally contain text equivalents that can be read by assistive devices.
One of the 16 Section 508 standards for Web applications concern non-text elements, including pictures, diagrams, charts, and maps:
The easiest way is to simply include it in the page in the surrounding context. Figure 4 is an example of contextual presentation from the Bureau of Justice Statistics Web site:
Property crime rates continue to decline
The HTML would be as follows:
<p>Property crime rates continue to decline</p> <img src="image/prop.gif">
Another way to convey this information is to include it in the tag used to insert an image reference in an HTML page. This tag can accept an alt attribute that contains a text description of the nontext element. (Although technically an attribute included in the image tag, such coding is typically referred to as an "ALT tag.")
The following code inserts the above chart into the HTML page and includes a description of the chart contents:
<img src="image/prop.gif" alt="Property crime continue to decline, 1973-2000">When a screen reader encounters this code, it reads the description in the alt attribute to the user. This method is generally used for short descriptions: many browsers limit the length of the text displayed from this tag. Adding ALT tags to images is not a difficult task. Many of the 508-remediation packages will prompt the user for a description when an image has been included without an alt attribute. Newer versions of Adobe Acrobat® and some authoring tools also provide a method to include a text description in their files. Of course, the software cannot assess the adequacy of the description. For many contemporary browsers, the text in the alt attribute is also displayed on the screen when a user mouses over the image, making proofreading of the descriptive text relatively easy.
Statistical charts, however, usually require more descriptive information than this to convey what is presented. For longer descriptions, a separate HTML file is used and may be linked from the image in several ways:
Figure 5 is an example of a chart from the Social Security Administration's Web site and its associated the long description, which is contained in a separate file.
Text description:
Change in median income, by marital status and race, selected years.
This line chart shows the change in median income in year 2000 dollars for married couples, nonmarried persons, whites, and blacks from 1962 to 2000. Income for married couples remained fairly level from 1962 to 1967 ($16,339–17,390). It then sharply increased to 22,781 and continued to steadily rise with some slight ups and downs until leveling off at 31,188 in 2000. Income for nonmarried persons began at $6,422 and rose very slowly to $12,715. For white persons, the 1967 amount,of 9,806, rose to 13,802 in 1971. It continued to rise without much fluctuation to 19,790 in 2000. The amount for black persons began at $6,929, rose slowly, and ended with a sharp increase to 12,333 in 2000.
Many statistical sites link the charts to the data in a table or list. This presentation works well for charts that have few data points, like pie or bar charts. However, it does not replicate the summarization provided by a chart based on many numbers.
For materials prepared one at a time by agency staff or contractors, providing text descriptions is not difficult. However, many agencies are providing dynamic charting capabilities. New products are available to create descriptions for dynamic charts. The National Cancer Institute is using such a product with their Atlas of Cancer Mortality Web site (http://cancer.gov/atlasplus).11
In addition, some screen readers now allow users access to a list of links included on a given page. As a result, developers must take additional care in labeling and differentiating their links so they are still meaningful when taken out of context.
Although text descriptions help to make graphics more accessible to those who are blind, users with low vision face different challenges in accessing graphics. Current graphic formats do not maintain underlying structural information about the image. As a result, users of screen magnifiers are presented with distorted, pixilated images rather than a nicely scaled version of a graphic. The Scalable Vector Graphics (SVG) format will address this limitation and should provide other support for accessibility as well.12
As discussed above, agencies are providing everything from minimal ALT tags to far more extensive descriptions of charts. In some instances, a table of the data is provided. Although all of these may meet the letter of the law, it is unclear if they meet the intent of the law to explain the meaning of the image. In some instances, the provision of large amounts of data in tables is not equivalent in purpose to showing the "big picture" that is the purpose of a graphic.
Recommendation: Advice from the disabled community is needed to determine what is useful. Additional research may be needed to determine what constitutes an equivalent or alternate description.
Some content, like maps with data and topographical symbols, contain too much data to summarize. Their value depends on special relationships not easily conveyed verbally. Several agencies provide a telephone number in the ALT tag for disabled users to call if they need the content explained. It is unclear if this is an adequate response or if there are other options.
Recommendation: The Access Board should provide agencies with additional guidance on this matter. The disabled community should provide guidance on what assistance would be helpful in lieu of an accessible alternative.
The current standards are intended to make Web pages accessible to assistive technologies that are based on text communicated by speech or Braille. Other assistive devices, including a tactile browser and an audio graphing calculator (where curves were rendered by the varying pitch of a sound), were demonstrated at the workshop.13 These devices rely on different means than the text-based technologies to communicate information. Such alternatives may be superior in conveying graphical content; however, the small customer base for such technologies has limited their development by commercial firms.
Recommendation: Additional research is needed to determine the most appropriate technologies for graphical displays. Also, there may be differences in how people who have never had sight and those who were once sighted perceive graphical information. Support for research and development of new technologies may need to be provided in a manner similar to that used for "orphan drugs."
Because currently supported graphic formats store information simply as a matrix of colored pixels, structural information is lost. As a result, that information cannot be used to clearly scale the image for users with low vision or for other assistive purposes.
Recommendation: Authoring tools, browsers, and assistive devices need to support SVG as soon as possible. Authoring software must allow the incorporation of information that may be used to enhance accessibility. Additional research is also needed to develop techniques for leveraging the structural information contained in the SVG format to make graphics more accessible.
Statistical agencies, like many agencies involved with scientific endeavors, use mathematical formulas based on notation that is not in the regular ASCII character set. Most agencies present formulas on Web pages as images. Therefore, the same requirements that apply to charts apply to formulas; a text rendering of the formula that can be read by a screen reader must be provided. However, writing complex formulas out in English is not a very elegant or usable way of presenting the information. In addition, although this method addresses the needs of blind users, it does not address the challenges faced by those with low vision. For example, an older user may need only to enlarge the font size on his or her browser in order to use the Web, but an equation that is inserted as an image will not scale proportionally with the text around it (see Figure 6).
Another method for presenting formulas on Web pages is MathML, an application of XML developed by the W3C. MathML can be used to encode both the presentation of mathematical notation for high-quality visual display and the mathematical content for applications in which semantics are key, such as scientific software or voice synthesis. MathML uses a tag set to identify the appropriate notation. Currently, only Netscape, Mozilla, and Amaya can display MathML directly. However, there are several add-on software packages that can enable MathML display in other popular browsers. At the time of the conference, none of the assistive devices were supporting MathML.
MathML is the standard for the presentation and communication of formulas. It is not yet universally supported in browsers or assistive devices. Without MathML, agencies must insert the formulas graphically and provide an alternative text description.
Recommendation: Clearly, MathML is the way that formulas will be presented on the Internet. It is imperative that the browsers and assistive technologies incorporate this standard. The statistical agencies should begin to tag their formulas using MathML.
Based on the attendance and attentiveness of the workshop participants, there is great interest in finding ways to meet the Section 508 requirements as they relate to statistical material. First and foremost, agencies are looking for clear guidance in what is needed to meet the requirements. Even though they are very willing to make their content conform, they often face serious resource constraints. Meeting the requirements falls short of the eventual goal: to make statistical content usable for all users.
Overall, the workshop was a good first step. It succeeded in drawing attention to the problems the agencies were having. Since the workshop, there has been progress. Technology has solved some of the problems, such as increased support for MathML. Several software vendors responded with improvements to their products that specifically answer the needs of the statistical agencies. In addition, several agencies have developed and implemented automated solutions.
However, more discussion with the disabled community is needed to ensure that the implementation methods selected meet the needs of that community. Additional research is needed to make statistical content usable to the disabled, to identify new ways of presenting statistics, to determine how these requirements could be leveraged to help sighted users, and to develop new methods for presenting statistical content to the disabled.
Statistical agencies produce thousands, possibly millions, of tables. The Section 508 standards require the identification of header information and its association with the data in each cell. The simplest tables have only one level of headers, placed in the same column or row as the data to which they refer. Such headers only need to be identified using <th> tags for assistive devices to properly associate them with the applicable data. However, complex tables, those with two or more levels of headers, require a significant amount of additional coding to make such associations because the headers do not have a predictable placement relative to the data. The FedStats 508/Accessibility Workshop identified the following issues and recommendations concerning tables:
| Issue | Recommendation |
|---|---|
There is no agreement on how to mark up tables. |
The federal statistical community should develop a recommended implementation for tagging statistical tables for accessibility. |
Assistive devices interpret various tags inconsistently. |
Technology is expected to converge with the standards. Recommended implementation should speed this process. |
Current technology does not allow visually impaired users to use the data as intended. |
Additional research on how to improve usability for the visually impaired. Develop new kinds of assistive technology. Develop additional markup tags and methods. |
Large, complex tables on the Internet may not be usable to the disabled or other users. |
Research the best methods of presenting numbers on a computer screen. Develop new publishing paradigms for the Web. |
Making tables accessible should not make them less usable to sighted users. |
Develop tagging options that will skip markup intended for sighted users. Develop techniques for associating footnotes and measurement notation with cells. Research how to do markup without increasing file size. |
Meeting the 508 standards for large, complex tables poses a resource problem for statistical agencies. |
Software vendors should focus on how their products can support batch processing and automation. Research how tagging might be used to help sighted users. |
No methods exist to validate the quality of markup for accessibility. |
New software is needed to assist in validating the markup. |
Most statistical agencies produce a large number of statistical graphics and charts, including maps. The Section 508 standards require a text description of all nontext elements. For charts with few data points, a link to the data in a table or list is sufficient. However, such alternative do not replicate the summarization provided charts based on many numbers. In addition, such summary descriptions are not easily generated for charts that are dynamically produced. The FedStats 508/Accessibility Workshop identified the following issues and recommendations concerning charts:
| Issue | Recommendation |
|---|---|
What should the text alternative for a statistical chart include? |
The disabled community should provide guidance on what is a useful alternative. Determine what constitutes an equivalent or alternative description. |
What alternatives are acceptable for content that cannot be made truly accessible, like maps? |
The Access Board should provide agencies with additional guidance on this matter. The disabled community should provide guidance on what assistance would be helpful in lieu of an accessible alternative. |
Existing assistive technology is not well suited to the presentation of statistical graphics or maps. |
Research the most appropriate technologies for graphical displays. Support for research and development of new technologies may need to be provided in a manner similar to that used for "orphan drugs." |
Current graphic formats do not maintain underlying structural image information. |
Authoring tools, browsers, and assistive devices need to support Scalable Vector Graphics (SVG). Authoring software must allow the incorporation of needed information. Develop techniques for leveraging the structural information contained in the SVG format. |
Like many scientific organizations, statistical agencies rely on mathematical notation to display formulas. Because this notation does not use the regular ASCII character set, many agencies use graphics to depict them. According to Section 508, formulas displayed graphically must be treated like other nontext elements and must have a description. The FedStats 508/Accessibility Workshop identified the following issues and recommendations concerning formulas:
| Issue | Recommendation |
|---|---|
Browsers and assistive devices do not yet fully support MathML, hampering the easy communication of formulas. |
Browsers and assistive technologies must incorporate support for MathML. Statistical agencies should begin tagging formulas using MathML. |
| Federal statistical community | Other government agencies | Statistical research community |
|---|---|---|
Develop a recommended implementation for tagging statistical tables for accessibility. Develop new publishing paradigms for the Web. Begin tagging formulas using MathML. |
The Access Board should provide agencies with additional guidance on what alternatives are acceptable for graphics that cannot be made truly accessible, like maps. Support for research and development of new technologies may need to be provided in a manner similar to that used for "orphan drugs." |
Research the best methods of presenting numbers on a computer screen. Research how table tagging might also be used to help sighted users. |
| Disabled and disability research communities | Web research community | Vendors |
|---|---|---|
Additional research on how to improve usability for the visually impaired. Develop new kinds of assistive technology that will allow visually impaired users to use tabular data as intended. Provide guidance on what a useful text alternative for a statistical chart should include. Determine what constitutes an equivalent or alternative description. Research the most appropriate technologies for graphical displays. Solicit guidance from the disabled community on what assistance would be helpful in lieu of an accessible alternative. |
Develop additional markup tags and methods. Tagging options are needed that will skip markup intended for sighted users. Develop techniques for associating footnotes and measurement notation with cells. Research how to do markup without increasing file size. Develop techniques for leveraging the structural information contained in the SVG format. |
Software vendors should focus on how their products can support batch processing and automation. New software needed to assist in validating the markup. Authoring tools, browsers, and assistive devices need to support Scalable Vector Graphics (SVG). Authoring software must allow the incorporation of needed information. Browsers and assistive technologies must incorporate MathML. |
8:00–8:30 Registration and Coffee
8:30–9:30 Opening
9:30–9:45 Break
9:45–10:00 Perspective of a Disabled User - Roger Keeney, American Council of the Blind
10:00–12:00 HTML Tables
12:00–12:30 Committee Recognition Lunch
12:30–2:00 Discussions of other possible solutions with workshop participants and vendors
2:00–3:00 Alternative Formats
3:00–3:15 Break
3:15–4:30 Graphics and Formulas
4:30–5:00 Conclusion and Future Directions - Laurie Brown and Marianne Zawitz, Workshop Co-chairs
5:00–6:00 Vendor Exhibits
Vendors participating:
|
Page Last Modified: May 16, 2007 |
|