5.4 Ensure that tables are accessible Tables can be complex, multi-dimensional structures. As such, they may be difficult to understand for users that browse in essentially one dimension, i.e. for whom tables are rendered serially. Large tables pose particular problems since remembering cell position and header information becomes more difficult as the table grows. Nested tables, likewise, create problems of orientation, as the user must recall the cell location within a cell location. Tables pose further problems because in many cases on the Web, they are used to lay out pages rather than to organize true tabular data. It is difficult for assistive technologies to distinguish tables used for layout from "real tables", and therefore renderings may confuse users. User agents can facilitate browsing of tables by providing access to specific table cells and their associated header information. How headers are associated with table cells is markup language-dependent. Tabular navigation is required by people with visual impairments and some types of learning disabilities to determine the content of a particular cell and spatial relationships between cells (which may convey information). If table navigation is not available users with some types of visual impairments and learning disabilities may not be able to understand the purpose of a table or table cell. There may be a variety of ways for a user to identify a specific table in a document (e.g., with the selection). Similarly, there may be a variety of ways to identify a specific cell (e.g., with the selection or via its row column coordinates). In order to provide access to tables for the widest range of users, the following features should be provided: [Priority 1] Provide access to the contents of a specific cell. [Priority 1] Provide access to header information for a specific table cell. [Priority 2] Allow the user to navigate among tables in a document. [Priority 1] Allow the user to navigate among table cells of a table (notably left/right within a row and up/down within a column). [Priority 2] Allow the user to search for a table cell based on its contents or header information. [Priority 2] Allow the user to select a table cell and find out its row/column coordinates in the table and to navigate to a table cell based on its row/column coordinates. [Priority 2] Allow the user to find out the dimensions of a table. [Priority 2] Allow the user to find out the number of tables in a document. Techniques for Tables 5.4.1 Provide access to the contents of a specific cell. [Priority 1] When a table is "read" from the screen, the contents of multiline cells may become intermingled. For example, consider the following table: This is the top left cell of the table. This is the top right cell of the table. This is the bottom left cell of the table. This is the bottom right cell of the table. If read directly from the screen, this table might be rendered "This is the This is the top left cell top right cell of the table. of the table." A user agent should provide a means of determining the contents of cells as discrete from neighboring cells, regardless of the size and formatting of the cells. A conforming user agent would allow access to the contents of individual cells either through the DOM or the API, so that this table might be rendered appropriately. 5.4.2 Provide access to header information for a specific table cell. [Priority 1] In data tables, the contents of a cell may be understandable only in context with the row and column designations. A user agent should provide a means of providing access to the contents of such row and column headers without shifting the point of regard of the agent. Possible solutions: * Provide info through an API. * Render cells as blocks (screen reader) Using this strategy, the user agent might render individual cells with the relevant top and side headers attached. * Allow navigation and querying of cell/header information. When the point of regard is on an individual cell, the user would be able to use a keyboard command to receive the top and left header information for that cell. The user agent should appropriately account for headers that bridge across multiple cells. * Allow user to read one column or row at a time (to help find headers). [Ed. Define algorithm for finding "header information" here. Does it come from THEAD, TH, attributes, HTML 4.0 algorithm for finding header information, etc. Allow the user to choose either "abbr" or what is calculated by the header algorithm.] [Ed. Discuss repair strategies for finding header information?] Since not all tables are designed with the header information, a conforming user agent should provide, as an option, a "best guess" of the header information for a cell. Possible strategies include: * Consider the top and left-most cells of a column or row to be header information. * Consider upper and left-most cells which have formatting markup to be header information. * Allow the user to navigate among tables in a document. [Priority 1] When rendering tabular information, the fact that it is tabular information should be apparent. For a visual user agent, such information is commonly made obvious by the border attribute. However, for a non-visual agent, such information must also be made appreciable. As the user agent shifts the point of regard to a table, it should first provide information about the entire table. This information might be the Caption, Title, or Summary information of the table. Access to this information would allow the user to determine whether or not to examine the contents of the table, or to move the point of regard to the next block of content. Allow the user to navigate among table cells of a table (notably left/right within a row and up/down within a column). [Priority 1] In many data tables, the meaning of the contents of a cell are related to the contents of adjacent cells. For example, in a table of sales figures, the sales for the current quarter might be best understood in relation to the sales for the previous quarter, located in the adjacent cell. In order to provide access to contextual information for individuals using non-visual browsers, or for individuals with certain types of learning disabilities, it is necessary for the user agent to allow the point of regard to be moved from cell to cell, both right/left and up/down via keyboard commands. The most direct method of performing such navigation would be via the cursor keys, though other navigational strategies might be used. Allow the user to search for a table cell based on its contents or header information. [Priority 2] Users of visual browsers can easily locate cells within a table that are at the intersection of a row and column of interest. To provide equivalent access to users of non-visual browsers, equivalent means of navigation should be provided. The search function of a browser will allow the user to locate key terms within a table, but will not allow the user to find cells that are at the intersection of rows and columns of interest. Possible strategies: * An advanced search mode might provide entries for header information, allowing the user to find information at the intersection of columns and rows using the key terms. * A search mode might allow the user to search for key terms that are related to key header terms, allowing searches to be restricted to specific rows or headers within a table. Allow the user to select a table cell and find out its row/column coordinates in the table and to navigate to a table cell based on its row/column coordinates. [Priority 2] Non-visual rendering of information by a browser or an assistive technology working through a browser will generally not render more than a single cell, or a few adjacent cells at a time. Because of this, the location of a cell of interest within a large table may be difficult to determine for the users of non-visual rendering. In order to provide equivalent access to these users, compliant browsers should provide a means of determining the row and column coordinates of the cell having the point of regard via keyboard commands. Additionally, to allow the user of a non-visual rendering technology to return to a cell, the browser should allow a means of moving the point of regard to a cell based on its row and column coordinates. Allow the user to find out the dimensions of a table. [Priority 2] At the time the user enters a table, or while the point of regard is located within a table, the user agent should allow an assistive technology to provide information to the user regarding the dimensions (in rows and columns) of the table. This information, in combination with the summary, title, and caption, can allow the user with a disability to quickly decide whether to explore the table of skip over it. Allow the user to find out the number of tables in a document. [Priority 2] Users of non-visual rendering technologies may wish, on entering a document, to determine the degree to which tables are used on the page. This information may allow the user to make guesses about the nature of the tables included (layout or data), and to relocate information that was previously browsed. Some general thoughts on table navigation techniques: * Users of non-visual rendering technologies and users with learning disabilities, when browsing a page, should be able to quickly determine the nature of a table located on a page. The able-bodied user is able to visually examine the table and extract a sense of the table contents with a quick scan of the cells. A non-visual user, or a user with difficulty translating printed material is not able to do this. Providing table summary information, when first moving the point-of-regard to a table allows the nature of a table to be easily determined. * An auditory rendering agent, when the point-of-regard moves to a table, might say, "Table: Tax tables for 1998," thus identifying the nature of the table. The user could then use keyboard commands to move the point of regard to the next logical block of information, or use a different command to "burrow" into the table. * The "burrow" command should have an opposite "pop" command, which would move the point of regard from an individual cell to the table as a whole, so that the user can leave a table from any cell within it, rather than navigating to the end. * If the user "pops" up to look over the summary information, it should be possible to "burrow" back to the same cell. * When navigating a table that contains another table, this strategy can avoid disorientation. For example, if each row of a table contained five cells, but the second row contained a 4x4 table in the third cell, a user could be disoriented when the row did not end as expected. However, when the point of regard moved to the third cell of the table, a compliant browser would report that this was a table, and describe its contents. The user would have the option of navigating to the forth cell of the parent table, or burrowing into the table within this cell.