This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The decision on ISSUE-130 opens up for some meaningless/meaningfull role changes for the "required owned children" [1][2] of layout tables. ISSUES/PROPOSALS: role=presentation is inherited by table's "Required Owned childen". [1][2] 1) Therefore <th>, <caption>, @summary, @headers and @scope, <tfoot> and <thead> should not occur inside layout tables, as they are meaningless there. Chances are that a layout table with such features a) was not intended as a layout table, e.g. these features (such as <th>,@scope,@headers) are meant for scoping, highlighting and navigation of data tables. b) could trigger data table handling in ARIA-unaware legacy AT c) could confuse authors, who might think that e.g. @headers will have effect, wheras in ARIA-supporting AT it is not likely to have effect. d) is seldom found in the wild 2) Positively expressed, it is suggested that layout tables may ONLY contain <table>, <tbody>,<tr>,<td>,<colgroup> and <col> 3) What about changing the ARIA role of table's required owned children? For instance, if <thead> and <tfoot> were permitted inside layout tables, should one then be allowed to do <thead role="banner"> or <tfoot role="contentinfo">? What about changing the role of <td>? PROPOSAL: EITHER one should freely be able to change the role of those required owend children that (per the outcome of this bug) are permitted inside layout tables. (Though <td role=spinbutton> and similar things might not be meaningful ...). OR one should not be able to change the role of the required owned children at all. In this case, one would have to add a <header> or a <footer> instead of using role=contentinfo and role=banner. 4) PERHAPSES: Should more than a single <tbody> be allowed? Should more than zero <colgroup> and <col> be allowed? Arguments in favour: - if it helps authors to avoid creating more than one table, then yes. - <col> corresponds to <tr> - logical to have same rules for both. - <colgroup> corresponds to <tbody> - logical to have same rules for both. Argumetns against: a) layout tables are often - and should be b) if permitted, then why shoudn't we, as well, permit tfoot, thead and th? References: [1]http://www.w3.org/TR/wai-aria/complete#presentation [2] http://www.w3.org/TR/wai-aria/complete#mustContain [Initial letter] http://lists.w3.org/Archives/Public/public-html/2011Mar/0332.html This bug relates to: http://dev.w3.org/html5/spec/tabular-data#the-table-element http://dev.w3.org/html5/spec/tabular-data#the-td-element http://dev.w3.org/html5/spec/tabular-data#the-tbody-element http://dev.w3.org/html5/spec/tabular-data#the-tr-element http://dev.w3.org/html5/spec/content-models#annotations-for-assistive-technology-products-aria
With (In reply to comment #0) One particular issue with regard to <tfoot> is that it can occur before the <tbody>, but that it will be rendered after all <tbody>ies. May be this one more reason to forbid <tfoot> in a table that is intended for layout.
Please read the text for role="presentation" where it defines the meaning of required owned children: "The presentation role is used on an element that has implicit native semantics, meaning that there is a default accessibility API role for the element. Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the grid role) require tr descendants (the row role), which in turn require th or td children (the gridcell, columnheader, rowheader roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as required owned elements." So, <th>, <tbody>, <thead>, <tfoot> etc. all disappear when mapping to accessibility API as these are considered required owned elements. Furthermore, platform accessibility APIs to date throw away tbody altogether when mapping to platform accessibility APIs. These are considered required owned elements as they complete the semantic structure of a table. I am not sure what it means to be a legacy AT. However, JAWS is what I consider to be a legacy AT and who supports ARIA. role="presentation" is applied to within Dojo and it does not have a problem with <th>, etc. When you apply a role on top of elements that are deemed presentational the assume the new role. so, I am having difficulty seeing the issue you are trying to raise. The ARIA spec. is clear.
(In reply to comment #2) > So, <th>, <tbody>, <thead>, <tfoot> etc. all disappear when mapping to > accessibility API as these are considered required owned elements. Likewise <table> disappears if one applies role=spinbutton. But it is still forbidden per the decision made on ISSUE-129 to do <h1 role=spinbutton>. Because it is meaningles to use that way. I have not claimed that it does not disappear - I have not used that kind of justification. > Furthermore, platform accessibility APIs to date throw away tbody altogether You mentioned above as well, that <tbody> "disappears" - I suppose "throw away" means the same. > I am not sure what it means to be a legacy AT. However, JAWS is what I consider > to be a legacy AT and who supports ARIA. This is what I said, quote: "ARIA-unaware legacy AT". I guess I could delete "legacy" and just say "ARIA-unaware AT". I've learned in public-html that even AT without ARIA support, discern between layout tables and data tables. I have also been told in the HTML wg that AT is updated at a much slower rate than other computer software. > role="presentation" is applied to > within Dojo and it does not have a problem with <th>, etc. My argument was not built on any assumption that <th> would be a problem for ARIA supporting AT. Please reread what I said. > When you apply a role on top of elements that are deemed presentational the > assume the new role. I do not understand how you could fail to notice that I was fully aware of this. In Comment #0 I said: 'role=presentation is inherited by table's "Required Owned childen"' > so, I am having difficulty seeing the issue you are trying to raise. The ARIA > spec. is clear. In this bug reports, I have not complained about ARIA's clarity. As I enumerated 4 points, I have difficulty know what you refer to. You see this from ARIA's point of view and from AT's point of view. I built an argument from author's point of view and legacy AT point of view (which I now for 2nd time have defined the meaning of). I also brought it how layout tables usually look like - as even data tables tend to not use <th>, I believe this is even more the case for layout tables. Btw, under 3) I took up this problem, which from ARIA's point of view, should be OK: <table role="presentation"><tr><td role=heading>Lorem</tr></table>.
(In reply to comment #1) > With (In reply to comment #0) > > One particular issue with regard to <tfoot> is that it can occur before the > <tbody>, but that it will be rendered after all <tbody>ies. May be this one > more reason to forbid <tfoot> in a table that is intended for layout. Indeed, I tested that kind of presentational table in VoiceOver on OS X 10.6. And VoiceOver read the content in "source order" - or "DOM order" - instead of the visual order. This, btw, seemed to be a consequence of <table role="presentation">.
I strongly suggest that you file one bug per issue.
(In reply to comment #5) > I strongly suggest that you file one bug per issue. This is about one issue: conformance requirements for "layout tables." This is now reflected in the title of this bug.
To the point about ARIA being unaware AT, ARIA is now part of HTML 5 per the chairs decision. Consequently, an AT either supports or does not support HTML 5. If an AT support HTML 5 it needs to support ARIA. An AT that does not support HTML 5 is going to have a lot more problems than just processing ARIA. So, why are we making a special provision for ARIA unaware AT? I am having difficulty understanding the concern.
(In reply to comment #7) > If an AT support HTML 5 it needs to support ARIA. An AT that does not > support HTML 5 is going to have a lot more problems than just processing ARIA. > > So, why are we making a special provision for ARIA unaware AT? > > I am having difficulty understanding the concern. This understanding difficulty that you claim, appears artificial. It is true that one must draw the line somewhere. But HTML5 does take into account that many user agents only support a subset of HTML5. (E.g. HTML5 offers authors to use <embed> or <object> as fallback for <video>.) I repeat: layout tables is a concept that was known to AT even before ARIA. Thus, the claim I've made in this bug report, is that it makes sense to make <table role=presentation> covers roughly that subset that legacy ATs (and, btw, probably not only legacy AT) treat as presentation tables. I believe that this is also what most perceive as "layout tables". Why do you want to widen that subset? Any use cases? Also, the author perspective, which you so far haven't touched: You once said that we don't want to punish those that added an attribute in order to be accessible. But I don't think HTML5 validity should be a matter of virtue ethics only. (http://en.wikipedia.org/wiki/Virtue_ethics). We need to consider the consequences and not only the virtue of the author. Otherwise we won't be able to help the author. Fact is: both <table role=presentation> and <td headers="idref"> are features that an author can use to be accessible. As such we could just say that, dear author, your intentions were the best, an hence - even if we don't have a slightest clue about about what you tried to do (because the one a11y attribute bangs the the other in the head), we don't punish you, because your intentions were the best. I'm also interested in your comment on the <tfoot> problem. Should the author's intension beat both conformance usability even in that case?
(In reply to comment #8) > (In reply to comment #7) Just a clarification: What I intended to ask in the paragraph is how a conformance checker react if a layout table contains a <td headers="idref">. > Fact is: both <table role=presentation> and <td headers="idref"> are features > that an author can use to be accessible. As such we could just say that, dear > author, your intentions were the best, an hence - even if we don't have a > slightest clue about about what you tried to do (because the one a11y attribute > bangs the the other in the head), we don't punish you, because your intentions > were the best.
I suggest to close this bug. (Since its status is "new" I cannot close it myself - is there something else I could do to bring it to an end?) Because: I don't have the energy to follow up on this. And if those who are supposed to know A11Y sees no problem with it, then ok. (The <tfoot> issue is probably only a bug in VoiceOver.)
I accept Richard's arguments. Plus: Not everything that is possible/legal to do would be smart to do. But this should be dealth with at author's digression and beest practises etc. In addition, we should look at any table as, in principle, a data table. Only tables with role="presentation" should be seen as being officially "blessed" (by the HTML specific) to be layout tables.
Bug triage team adding the a11yTF keyword, though the bug is closed and shouldn't be re-opened.
mass-moved component to LC1