Accessibility Minutes 2015 02 20

From MemberWiki

Jump to: navigation, search



  • Jon Gunderson (University of Illinois) - Chair
  • Marc Johlic (IBM) - scribe
  • Nicholas Hoyt (University of Illinois)
  • Ann Abbott (IBM)


TOPIC 1. Use of GitHub for bug and feature tracking

TOPIC: 2. Goals for next release of ruleset 0.9.8

· Updated data table rules

· By pass blocks link

· Rules for manual checks for linking to non-HTML resources

· Reviewing a group of rules messaging (e.g. table rules, …)

JG: Need to a rule for linking to non-HTML resources (PDF, media files, etc)

JG: We could add rules for checking these and having meta info that would describe these resources

JG: Would provide a way through current tool to highlight these types of resources

JG: Anyone have time to review some of these messaging rules?

Currently both Ann and Marc are completely booked

JG: Jon and Nick will talk about it on Tues meeting

TOPIC: 3. Updated data tables rules

· Use “Caption” and “Summary” terminology

· Rules for caption and summary are recommended

· Complex and large table definitions

o Large tables are currently defined as over 64 cells

· Unique captions is a required rule (e.g. making captions required when more than one data table is on a page)

JG: Originally looked like caption and summary would be deprecated out of HTML5 - but they have made it in

JG: Added rules - Recommended - to have a caption and a summary

JG: Changed a third rule so that if there is more than one data table on a page, then caption should be unique

JG: and if you did not have a caption it would be a Failure

AA: That would change it from being Recommended - WCAG does not have that as a Failure

NH: Question about summary - caption seems like it could be useful in all situations, but what about summary?

JG: For summary, it's only recommended for large or complex tables


MJ: From WCAG on complex tables: "The summary is useful when the table has a complex structure (for example, when there are several sets of row or column headers, or when there are multiple groups of columns or rows). The summary may also be helpful for simple data tables that contain many columns or rows of data."

JG: Other trigger for the rule is if the page has more than 64 cells

JG: Should we have this rule for large tables?

NH: Doesn't seem like we need summary for large tables

AA: Agree - don't need for large tables

MJ: +1

AA: Does caption get announced before summary?

JG: Yes caption is announced before summary

AA: And are they announced before the table data?

JG: There are keys to move between tables on a page - so you're outside the table and you ask to move to the table - and that is when caption and / or summary would be read

MJ: From WCAG "If both a summary attribute and a caption element are present for this data table, check that the summary does not duplicate the caption."

JG: Can add a rule for summary duplicating caption

NH: The language in the table rules says "Data table *must* have captions" - but they are Recommend

NH: Should use *should* if Recommended

JG: Will take a look at that

AA: The summary attribute is only required for data tables that have a complex structure such as:

AA: Data tables that have two or more levels of row or column headers implemented using any of the following ways:

AA: a table with two or more tr elements that contain only th elements

AA: a tr element that contains at least one td element and two or more th elements.

AA: a thead element that contains two or more tr elements

AA: a table with more than one thead element

AA: Data tables where headers span multiple rows or columns, such as the table pictured in HTML example 3 implemented in either of the following ways:

AA: a td element with a rowspan or colspan attribute

AA: a td element with a headers attribute value that contains more than two IDREFs

AA: Data tables in which the table headers are not located in the first row or first column of the table, such as in HTML example 5.

AA: Use the summary attribute of the table element to give a brief overview of data tables. Use the summary attribute to provide additional information about the structure or purpose of a data table to a screen-reader user. Unlike the caption element, the summary attribute is not visible, but it is spoken by screen readers. If a caption is also specified for the data table, ensure that the

AA: caption text does not duplicate the summary text.

IBM checklist requires summary attribute for complex tables (as defined above)

AA: Specifying a caption on a data table is optional. However, if a caption is specified, the element must be used to programmatically associate data table captions with data tables. If a summary is also specified for the data table, ensure that the caption text does not duplicate the summary text.

NH: Rule Table 3 should say "Complex Data tables must have summary"

JG: Rule that states if there is more than one data table on the page, then they are required to have unique captions

AA: Think that needs to be Recommended - WCAG does not require

NH: Should we even *recommend* that all data tables need captions? Some tables are probably self-explanatory and or small and would not need a table

AA: Agree that it could lead to over-verbosity on the page

NH: If you had a table with aria-label that could provide the accessible name

JG: Agree

AA: Maybe change wording in summary to "Data tables should have accessible names"

AA: and then in details describe using caption element and / or aria-label , aria-lablledby

JG: So Recommended that data tables have an accessible name, Required that complex tables have an accessible description

NH: Question on Table 1: Data cells must have headers - are you referring to header attribute?


NH: References "header cells"

NH: Alternative definition could be:

NH: Data cells in data tables must have header cells

NH: change to column and/or row headers

NH: Each td element in a complex data table must have a headers attribute that references the id attributes of associated th elements.

JG: Maybe we need 2 rules - one for simple and another for complex tables

JG: Split Table 1 into 2 rules

AA: Use table markup to present tabular information. The most basic type of data table contains one row of column headings and/or one row of row headings. Use the <th> element to identify table heading cells of rows and/or columns in a simple data table.

AA: Use id and headers attributes to associate data cells with header cells in complex data tables. Complex data tables are defined in HTML example 4 below. Complex data tables require additional markup to associate the heading explicitly with the data. In the data cells, the headers attribute is used on the <td> element to specify the heading cell, via the id attribute on the <th> element, that

AA: is associated with a specific data cell. If the data table has headers that are not located in the first row or column and does not have multiple levels of headers, you can use the scope attribute instead of using the id and headers attributes.

JG: Will work on these changes and we can review them next week

AA: Sometimes the scope attribute can be used instead of the id and headers attributes to define the scope of header cells within a data table. Whenever table headers are not located in the first row or column, and there is a single level of headers, you can apply the scope attribute to identify a cell that is a header for a row, column, group of rows or group of columns. The scope attribute is

AA: used in addition to the <th> element; it is not used in place of the <th> element.

AA: The value of row in the scope attribute will assign the cell as the header for all cells in that row. Similarly, the value of col in the scope attribute assigns the cell as the header for all cells in that column. The scope attribute is generally quicker and easier to use than id and headers attributes for simple tables.

NH: Layout 1 rule - the rule summary doesn't make it obvious why this rule is in the Tables section

NH: Question on Table 5 - summary doesn't help understand what this is about. When i look at the definition, I think the purpose is that we want people to make it explicit when using table markup for something other than a data table.

JG: We don't want ambiguous tables

JG: If we don't find any markup that this is a table rule, this rule kicks in

NH: "Defining" it sounds like there's something that needs to be added to define

AA: How about "distinguish"

NH: I think that gets closer

AA: "Distinguish between layout tables and data tables

AA: There are two types of tables that are used in HTML. Data tables contain multiple rows and columns and are used to present information to a user in a clean, concise manner. Layout tables are used to lay out the images and text on a page. Layout tables do not contain tabular data and are only used for the visual layout.

NH: Table must be "identifiable"

AA: But if you're using role="presentation" then it won't identify as a table at all

JG: Lots of edits to make here

JG: Needs to be some work on all of the metadata as well

AA: Has this call been cancelled during CSUN?

JG: Deleting meeting invite now

JG: No call March 6th

JG: Anything else for today?

JG: Can I go ahead w/ changes from this morning - the Required to Recommended?

JG: Heading 3 changed to Recommended and Link 1 to Recommended

Call ended at 4:00 pm EASTERN

Personal tools