Wednesday, October 19, 2011

Data vs layout table

Tables in accessible world may be treated as data or layout table. The data tables are supposed to contain data and user should be able to navigate through its structure and get information like headings. Typical example of data table is grid. Layout tables are supposed for elements arrangement on the screen and structure of these tables is likely ignored by AT.

Firefox provides semi-standard layout-guess object attribute on table accessible to say whether this table is for data or layout. Shortly, this attribute is exposed for layout tables only, for data table it's omitted. This object attribute wasn't adopted by IAccessible2 or ATK specifications yet but there is discussion on IAccessible2 list.

Firefox relies on the following algorithm to detect whether the table is layout or not. The algorithm stops when it hits the item. Note, the algorithm is applicable to accessible HTML tables only (check out when HTML table has no accessible).

Algorithm
  • Table inside editable area is data table always since the table structure is crucial for table editing
  • Table having ARIA table related role is data table (like ARIA grid or treegrid)
  • Table having ARIA landmark role is data table
  • Table having datatable="0" attribute is layout table (Firefox 10)
  • Table created by CSS display style is layout table (Firefox 11)
  • Table having summary attribute or legitimate data table structures is data table; these structures are:
    • caption element
    • col or colgroup elements
    • tfoot or thead elements
    • th elements 
    • header, scrope or abbr attributes on table cell (Firefox 13)
    • abbr element as a single child element of table cell (Firefox 13)
  • Table having nested table is layout table
  • Table having only one row or column is layout table
  • Table having many columns (>= 5) is data table
  • Table having borders around cells is data table
  • Table having differently colored rows is data table
  • Table having many rows (>= 20) is data table
  • Wide table (more than 95% of the document width) is layout table
  • Table having small amount of cells (<= 10) is layout table
  • Table containing embed, object, applet of iframe elements (typical advertisements elements) is layout table
  • Otherwise it's data table

Updated to Firefox 13.

12 comments:

  1. You really have an attribute where "0" means false?

    ReplyDelete
  2. We follow what users do on the web. The Putting datatable="0" attribute on HTML table is common practice to make sure the JAWS treats the table as layout table. We adopted this feature. If there's a reason we should support other values of this attribute then I'm sure we can do that too.

    ReplyDelete
  3. A couple of questions.
    1) Is this exposed as an attribute I can read in JavaScript or is this only available via the accessibility API?
    2) I'm confused why having a landmark role makes something a data table. Surely adding a role on table overrides the native semantics and essentially makes the table presentational
    3) I'm assuming a step has been omitted. A table with role="presentation" should be a layout table.
    4) I'm assuming these are evaluated in order and if any item is matched the algorithm stops.
    5) I'm really confused by "Table having nested table is layout table". It is quite possible (and actually relatively common) to have a nested layout table within a data table. It is only a nested data table which is problematic. If we have a nested layout table within a data table where we are using headers and ids to mark the association between header and data cells does this mean this would be recognized as a layout table? This doesn't seem correct.
    6) Legitimate data cell structures should include the headers or scope attributes on any cell within the table. Also the abbr attribute on header cells is only really valid in data tables.
    7) Does any AT actually use this at the moment?

    ReplyDelete
  4. Hi, James.

    1) It's exposed by IAccessible2 on Windows, ATK on Linux, nsIAccessible XPCOM interface for JS. Note, if your application/service/whatever is not accessibility targeted then I strongly don't recommend you to use it.
    2) This algorithm leaves behind the cases when we do not create a table accessible. So if the HTML table element has ARIA role that change native semantics then no table accessible is created and layout-guess is not applied at all. So if we have a table accessible having landmark then it's likely a data table, at least I don't see a reason why the user would need to navigate to presentation things.
    3) This one is similar to 2nd item. No table accessible is created in this case.
    4) Correct, you hit next item if all previous didn't return.
    5) You never hit this item if one of aboves worked out. So the answer is no because this case should be covered by "table having summary attribute or legitimate data table structures is data table" item.
    6) Agree. Will fix it. Thanks!
    7) As far as I know NVDA relies on it.

    ReplyDelete
  5. Thanks Alex - that is very useful information. This would be used in an accessibility testing tool so it seems like it would be appropriate to use it.

    I'm still confused about (2)
    If I have <table role="banner"> then a table accessible would not be created as the role overrides the native semantic. How would I create a table accessible with a landmark role and still have a table accessible in the accessibility tree?
    Even if this were possible (and I don't believe it is) then the presumption that a user does not want to navigate to a layout table seems misguided. It would seem to be common when using tables for layout that a particular table may contain a landmark.

    I think the reason this isn't an issue is that "Table having landmark" is just not possible.

    ReplyDelete
  6. Hey, James. Yes, accessibility testing tool fits perfect. You should use accessibility service to acquire table accessible for HTML table element:
    var accRetrival = Components.classes["@mozilla.org/accessibleRetrieval;1"].getService(nsIAccessibleRetrieval);
    var accessible = accRetrieval.getAccessibleFor(HTMLTableDOMNode);

    You might run into security restrictions, for that you should ask the user for privileges.

    I'd say ARIA role="banner" doesn't override native semantics, it rather adds new one. Firefox still creates table accessible, the table role is exposed and role="banner" doesn't affect on set of implemented interfaces. So from AT point of view this is still a table accessible.

    I believe the web has opposite examples for this case. Actually we have three options to proceed it:
    # treat as layout table;
    # treat as data table;
    # don't take into account presence of ARIA weak landmarks.
    Basically either option can be considered as valid. However we might want to follow 3d option as most neutral one. But I don't have strong opinion on this.

    ReplyDelete
  7. Thanks. Security restrictions should be fine as its an add-on.

    For the weak aria landmarks I'll bring this up at the PFWG Face to Face meeting at TPAC next week and see what the opinion is.

    ReplyDelete
  8. Thanks! Please let me know what opinions are.

    ReplyDelete
  9. Has the datatable attribute been proposed for any spec? If not, why not and will it be?

    ReplyDelete
  10. As far as I know it's not a part of any proposal. Maybe it could be adopted by HTML spec for pure accessibility purposes. I'll ask around.

    ReplyDelete
  11. datatable=0 was a Freedom Scientific thing predating role=presentation.
    I wouldn't be in favour of adding it to any spec (there were also a whole host of bugs in the implementation too)

    ReplyDelete
  12. Thanks, James. That's right. ARIA role="presentation" is standard way to do that.

    datatable="0" support in Firefox is all about to keep certain web pages in more accessible way.

    ReplyDelete