Wednesday, October 26, 2011

When HTML table is an accesible table

In addition to previous topic Data vs layout tables another aspect of the issue is when layout-guess computation algorithm is applied for HTML table elements.

Shortly the algorithm starts working if HTML table element has associated table accessible. In particular that means it doesn't run if HTML table is not accessible, i.e. it doesn't have any associated accessible object in the accessible objects hierarchy. This happens if HTML table is
  • not visible (CSS display:none or visibility:hidden styles are applied)
  • not focusable and ARIA role="presentation" is used on it.

Another case is when table element is accessible but it's not a table accessible. From AT perspective the table accessible is an accessible object that exposes a number of table specific interfaces (like IAccessibleTable2 in case of IAccessible2) and has proper accessible roles (like MSAA table or outline roles). So this case is effective (no table accessible is created) when ARIA role used to override native semantics is set on the element, for example role="button". Note, the same time weak ARIA roles like role="banner" don't affect on table semantics and the element gets treated as a table by AT.

In either case HTML table accessibility state affects on its underlying accessible hierarchy. So that if HTML table is not accessible or is not a table accessible then no table structure is exposed, i.e. no rows and no cells.

Also table accessibles may be created for elements different than HTML tables. There are two options to do that:
  • CSS display:table
  • table specific ARIA roles like role="grid" or role="treegrid".
The layout-guess algorithm returns true in former case and false in second case.

No comments:

Post a Comment