Evaluated KRAD on http://dev.rice.kuali.org/portal.do
Evaluated with latest Firefox (5.0) on Vista & XP PCs, with latest JAWS (12.0), and with Safari on MAC with VoiceOver.
Evaluated in "say all" mode and in "forms" mode.

Evaluated KRAD on http://dev.rice.kuali.org/portal.do
Evaluated with latest Firefox (5.0) on Vista & XP PCs, with latest JAWS (12.0), and with Safari on MAC with VoiceOver.
Evaluated in "say all" mode and in "forms" mode.

1. Table summary tags. Recommendation is to add the appropriate table semantics/structure as detailed below, rather than to add a summary tag. If not possible to fix the table structure, then add and populate the summary tag. Background details: See http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H73. With other good table structure, not having the summary tags wouldn't make us inaccessible. The "summary" attribute is only required if the actual table name (i.e. as provided by a <caption> element, a "title" attribute or an "aria-labelledby" attribute) is not sufficient. In that case, the summary attribute is used to provide a textual description of the information and structure that the table provides.

2. Header attributes on the td tags where the cells include a link. Recommendation:
Add header attribute on the td tags that include a link. Background details: If the table is marked up correctly screen readers, e.g.JAWS, will announce the headers before announcing the cell values. See http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/H79. For most problematic example/location, see the travel account inquiry page. The cells with the links in the main tables on this page (e.g. "a14") don't have header attributes on the td tags. And the cells in the table at the bottom of that same page with links also don't have them. The header attribute is particularly useful for complex tables where a cell's associated headers cannot be reliably determined from the table structure.

3. Missing column and row header scope attributes (scope='') on the td tags. See http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H63. For example problem table, see the "Fiscal Officer Accounts" sub-section at the bottom of the travel accounts inquiry page. The content is created as two separate tables, one for the headings (JAWS reads "table with 5 columns and 1 row" and reads across it) and a different table for the content (after reading the headings table, JAWS reads "table with 5 columns and 5 rows" and reads across each row, then continues to the next row). This is a problem as there is no way for non-sighted users to associate the row contents with the headings or even to tell when one cell ends and another begins. For a proper column header announcement the screen reader must perceive the table as one single structure. This means that the best way is to mark up the table up using one <table> element, and mark up the column headers appropriately.

However, if instead, this MUST be 2 tables (for widget/sorting capabilities, etc.), the 2nd table must have table structure tags that associate each cell with the appropriate column label provided in the 1st table, so a screen reader can announce in the second table the appropriate semantic information with each cell's content. There are two potential fixes for this, detailed below:

3.a. Fix alternative a = To fix the broken table structure for browsers that support ARIA, do the following:

Wrap a single <div role="grid" aria-readonly="true"> around both tables.

Add row="presentation" to each individual table element.

Because role="presentation" removes all native roles for the rows and cells inside the table, you have to re-apply them using ARIA as well: Use role="row" for <tr> elements, role="columnheader" or role="rowheader" for <th> elements, and role="gridcell" for <td> elements.

3.b. Fix alternative b = Fix for all browsers (non-ARIA as well as ARIA): Add hidden Column Headings. With this approach a column header row is added to the 2nd table. In this case there would be two column headers: one for the property name column and one for the property value column. To maintain the same visual appearance, this row can then be hidden off screen using CSS while keeping the information available for screen reader users:

4. Missing rowspan and colspan tags in table definitions. See http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H43.html. For example, text headings are used instead of column headings in places in tables (for example "Old", "New" in the travel account maintenance edit page are heading level 4s). Impossible for non-sighted user to understand the semantic relationship with the cells. Without proper table markup (since this is a table) it is confusing: user is told there is a table with 4 columns and 9 rows, then the screen reader starts out by reading old, then new – most people will assume this is the first two columns in the first row, and will be listening for the next two items in that row.

We could create a 3-column table instead, where the first column contains the variable name, the second column contains the old value and the 3rd column contains the input controls for the new values. Or we could add rowspan and colspan tags on the table header definitions of the current 4-column table to properly mark up the old and new headings that span multiple columns.

Brian Smith (Inactive)
added a comment - 01/Apr/14 1:05 PM Yes, its asking for mostly the same stuff, but I am struggling with the changes we need to make here, as it appears some of this is already correct in the current version.