- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 1 Sep 2010 08:34:21 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: James Craig <jcraig@apple.com>, public-pfwg-comments@w3.org, Steve Faulkner <sfaulkner@paciellogroup.com>
- Message-ID: <OF52F8A298.A6398093-ON86257791.0049680F-86257791.004A8F4F@us.ibm.com>
Rich Schwerdtfeger CTO Accessibility Software Group Maciej Stachowiak <mjs@apple.com> wrote on 08/31/2010 05:10:39 PM: > From: Maciej Stachowiak <mjs@apple.com> > To: James Craig <jcraig@apple.com> > Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Steve Faulkner > <sfaulkner@paciellogroup.com>, public-pfwg-comments@w3.org > Date: 08/31/2010 05:10 PM > Subject: Re: Please clarify ARIA definition of "grid" role > > > On Aug 31, 2010, at 2:30 PM, James Craig wrote: > > > On Aug 31, 2010, at 7:40 AM, Maciej Stachowiak wrote: > > > >> On Aug 31, 2010, at 4:45 AM, Richard Schwerdtfeger wrote: > >>> If we are going to defined the table element in terms of ARIA > semantics whereby our define of grid one one of an interactive > table, then we have only two choices: > >>> > >>> - take our first proposal which states that Table has no default > ARIA semantics, which is true. > >>> - If we are going to define Table in terms of ARIA semantics > then we would need to define table in terms of a static non- > interactive, non-navigable ARIA grid. The HTML specification does > not state that a table is not non-interactive nor does it state that > it can't be me made navigable. The only thing it states that a > <table> can't be used for is layout (which I disagree with and is > inconsistent with worldwide web usage of table). Yet, a table allows > an author to apply script to it to change its functionality. > >>> > >> I think the first option is superior. If <table> does not satisfy > the "grid" role by default, then it should just have no role. I > don't think it's helpful to say it is kind of a grid but not really. > > > > This still isn't right. The BaseConcept of grid is "HTML table", > and the Required Owned Elements for grid are: > > • row > > • rowgroup → row > > > > Last November at the F2F, we added the rowgroup role specifically > so that ARIA grids could have role symmetry with the HTML table > child elements thead, tbody, and tfoot. > > > > rowgroup http://www.w3.org/WAI/PF/aria/complete#rowgroup > > BaseConcept: HTML thead, tfoot, and tbody > > Note: This role does not differentiate between types of row > groups (e.g. thead vs. tbody), but an issue has been raised for WAI-ARIA 2.0. > > > > One of the reasons we needed role symmetry was due to the > complexities of presentation inheritance with host language implicitsemantics. > > > > From the spec: http://www.w3.org/WAI/PF/aria/complete#presentation > > Would this imply that the "grid" definition *should* cover non- > interactive presentations of tabular data, such as HTML <table>? > That is fine by me. I just want the ARIA spec and the HTML5 spec to > be in sync on this. The thing I didn't like about Rich's proposal is > that it would make HTML <table> be a "grid but not really". I don't > think that is a useful state. Either it's a grid or it's not. > I agree Maciej. I would prefer that authors use an HTML table when they need it at this time. We don't have support for things like rowspan and columnspan at this time. If authors need that capability they simply apply aria grid, gridcell, rowheader, colheader semantics, etc. on an HTML table. One possibility would be to introduce an ARIA abstract role of Table to introduce the concept of static tabular data and have that apply to an HTML table. This would basically state that a table maps to an ARIA abstract role but has no direct implementable ARIA role in ARIA. In our HTML 5 API mappings we would simply identify the actual accessibility API mappings for tables. This would not impact Last Call as there is nothing to implement given that table is an abstract class. We can give it the same one line definition as HTML 5. > I have no personal stake in the question of whether it is actually a > grid. I just want it to be one or the other. > > Regards, > Maciej >
Received on Wednesday, 1 September 2010 13:34:59 UTC