From : Sam Ruby < : Sam Ruby < rubys@intertwingly.net



Message-ID : <4D790C08.2020200@intertwingly.net>

To : HTML WG < : HTML WG < public-html@w3.org



The decision follows. The chairs made an effort to explicitly address all arguments presented in the Change Proposals on this topic in addition to arguments posted as objections in the poll. *** Question before the Working Group *** There is a basic disagreement in the group as to whether table elements which specify role="presentation" are to be considered conforming. The result was an issue, two change proposals, and a straw poll for objections: http://www.w3.org/html/wg/tracker/issues/130 http://www.w3.org/html/wg/wiki/ChangeProposals/layouttables http://www.w3.org/html/wg/wiki/ChangeProposals/NoLayoutTable http://www.w3.org/2002/09/wbs/40318/issue-130-objection-poll/results == Uncontested observations: * Tables are used for presentation extensively throughout the web. * HTML 4 states that tables should not be used for layout * We should encourage device independency * the feedback from the web authoring community over the years has been that they want to move away from (ab)using HTML as presentational language. * WAI WCAG discourages the use of a table element for anything that's not a real data * Compared to CSS, tables take more bandwidth, they aren't as cacheable, they require you to cut images, they result in pages that aren't as maintainable, and aren't rendered incrementally in many browsers. * The WAI has developed an ARIA role that is now supported in IE, Firefox (Windows and Linux), and Safari called "presentation". It is also used extensively on the web in libraries like Dojo, hundreds of Web 2.0 applications and key assistive technologies like the JAWS screen reader. When applied to a table it provides a declarative way of stating that the table is being used for layout. None of these were decisive. There were people who supported either of these proposals even after taking these facts into consideration. The fact that they were acknowledged up front was appreciated. We further note that there were plenty of variations of the sentiment that tables should be discouraged. === Objections We start with what was found to be the strongest objection, which was the combination of the following two statements: a winning accessibility strategy is one that does not put an incredible burden on the author. Expecting authors to rewrite their web applications to support such a pervasive coding change as to use CSS table layouts only infuriates the development community resulting in tremendous pushback on accessibility in organizations. It is much less invasive to add an attribute to convey the intent of the author. This approach is much easier to implement by authors who have made sizeable investments in the use of tables. It is a much lighter weight change than having to convert numerous applications, like databases to use a CSS Table approach when generating web content. The only way to accurately detect a conformance violation is if the author set role="presentation" on the table thus penalizing authors for producing accessible content. Taken together, making the use of role="presentation" on table elements would have the effect of discouraging people from making their content accessible; and we find that there are strong objections for this to be done by HTML5. Following are the remaining objections that we were able to extract. Each of these are direct quotes followed by an analysis of the strength of the objection. some scenarios presentational tables are perfectly legitimate. The strength of this objection was weakened considerably by the fact that no specific scenarios were enumerated. We note that another response to the survey indicated that "tables provide a consistent layout across browsers.". Taken together, this strengthens the objection that was already found to be the strongest. Since HTML4 and before, "don't use table-based layouts" has been one of the loudest and most consistent evangelism points. This argument cuts both ways. In response to the survey, we see "the industry has clearly ignored for over a decade despite the statements in the HTML 4 specification." We note that we've seen this argument before. In a previous survey it was observed that "no stated reason that this ... will actually be used more in the coming 10 years than it has in the past 10 years" to argue that a given feature should NOT be adopted/retained. Any argument that can be used both ways is necessarily a weak argument. Over the past decade or more, Web designers have been moving away from tables for layout. For a while, limitations in the market leading Web browser made this somewhat impractical for sites with complicated flexible layouts that had to be compatible with a broad range of user agents, but this is no longer the case, and new sites can avoid using tables without difficulty. Old sites won't change, but old sites are not affected by changes to conformance criteria, since they already exist. Conformance criteria only affect actively developed sites, and those can move away from tables (and many avoid using tables at all). This assertion does not mention a specific example. By contrast the authors of the proposal to make <table role="presention"> conforming cite gmail, facebook, yahoo mail, numerous IBM applications, and toolkits such as DOJO and YUI. As each of these are actively maintained, we find that there was insufficient evidence provided to back up this assertion. I strongly object to this proposal. HTML is not a presentational language. If we want to turn it into a presentational language, or some kind of hybrid, we should apply that universally and not just punch a hole for tables. Another response to the survey states "Currently, I don't see a compelling story behind what the spec forbids and what it allows (witness other exceptions, such as what kind of values are allowed on iframe/@width)." Therefore, at the present time we do not find there to be consensus within the Working Group as to whether or not HTML contains markup for presentation purposes. Nor is it our intent for this decision to cover anything other than the scope of the original issue. Note that we have included any potential future finding of consensus on when presentational aspects are to be allowed as potential "New Information" sufficient to cause this issue to be reopened. ... and actually removes the confusing table semantics from the platform accessibility API producing a reliable accessible solution and improving assistive technology processing performance." It is not clear what is being removed (i.e., it is doubtful that all of the unannotated use of tables for presentational purposes will be corrected), and there is no data provided on reliability and performance. As such, this is a weak objection. From an accessibility standpoint, there are a couple of issues: screenreaders switch into a table browsing mode, thus navigation between data cells is different and much more complex than just reading a text. So table layout adds a burden to a screenreader user. Also the content of pages with table layout tends to be confusing when read in source order, even when the visual representation is clear to a sighted user. role="presentation" doesn't change this. This was countered two separate times: Although in RNIB we agree that using tables for layout is not always good practice (CSS is in most cases a more appropriate choice), we also think that the assumption that screen readers can't cope with layout tables is as flawed as the assumption that all screen readers can cope with the less rigid structure of CSS presentation. There are developers/authors who would persist in believing that layout tables are bad for screen readers. They aren't. Bad ones are, as is the inappropriate use of CSS layout. In all, we find that the case was not made that role="presentation" "doesn't change this". It is important to remember that there are more than two kinds of user agents; there are at least three... User agents without CSS support or without scripting support, and certainly without ATs, which always use the default semantics of the elements. This is potentially a valid objection, but fails to explore what happens in the case where such a user agent does not support ARIA, nor the case where such a user agent does support ARIA. In the former case, it does no harm. In the latter case, the result would entirely depend on how ARIA was supported. In the course of this discussion, a large number of specific examples were provided where existing sites utilized markup in a way that could benefit from the "change some role mappings" proposal, and absolutely none were identified which would harm the user agents which do not support CSS or scripting but does support ARIA in some fashion. As such this objection was considered to be weaker than than the objections to the alternative. === Arguments not considered: Each of these are direct quotes followed by a reason why the objection was not considered: I object, we don't need this. It is unnecessary, tables are for tabular data. </story> This objection fails to make any sort of case. Additionally, neither Change Proposal suggested any change in User Agent behavior for role="presentation". practically, i can live with this change proposal, PROVIDED that: We only evaluate change proposals which actually were submitted. This recommendation should be present in some sort of best practice document for HTML authoring or in accessibility guidelines, not directly in HTML5 spec. We only evaluate change proposals which actually were submitted. using reverse-engineered heuristics to establish the semantic nature of something is flawed. Declaratively marking a table with role="presentation" is about as clear as it gets. No change proposal suggested either removing this attribute or changing the heuristics. *** Decision of the Working Group *** Therefore, the HTML Working Group hereby adopts the "Allow tables to be used for presentational purposes" Proposal for ISSUE-130. Of the Change Proposals before us, this one has drawn the weaker objections. == Next Steps == Bug 10963 is to be REOPENED and marked as WGDecision. Since the prevailing Change Proposal does call for a spec change, the editor is hereby directed to make the changes in accordance to the change proposal. Once those changes are complete ISSUE-130 is to be marked closed. == Appealing this Decision == If anyone strongly disagrees with the content of the decision and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request. == Revisiting this Issue == This issue can be reopened if new information come up. Examples of possible relevant new information include: * evidence that correct usage is growing rapidly and that that growth is expected to continue. Ideally, this usage would include a large of the sites that were cited, namely gmail, facebook, yahoo mail, IBM applications, and toolkits such as DOJO and YUI. Alternatively, this evidence could include some rationale as to why the cases which are cited should outweigh the evidence provided by these cases. * a substantial list of User Agents which are scripting unaware and CSS unaware but are partially ARIA aware to the point where the addition of role attributes produces substantially worse results than not having such information available provides. This list would need to be accompanied by a specific list of sites that employ such problematic markup. Ideally such evidence would be provided in terms of first hand statements by implementers of these tools themselves. * A comprehensive document over which we have found there to be W3C Consensus within the Working Group which defines the strategy by which HTML5 approaches making choices for dealing with presentational aspects of the language, as well as a comprehensive mapping of this strategy to the markup language that HTML5 defines.