- From: <bugzilla@jessica.w3.org>
- Date: Sun, 22 Aug 2010 06:45:49 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10066 --- Comment #14 from steve faulkner <faulkner.steve@gmail.com> 2010-08-22 06:45:48 --- maciej wrote: > 2) Elements that have their default role changed > > These differences seem more individually notable than the others, and may be > oversights in either the current spec or the proposal. They might be worth > extra attention. > > details - changed from no role to "button" role from reading the spec we concluded that details may have a default role of button as it is likely to be the element a user will interact with to show/hide the details content. > input type=file - changed from "button" role to no role in the majority of cases this is a composite control consisting of a button and a text box. refer to www.456bereastreet.com/archive/200410/styling_even_more_form_controls/ for example browser rendering of this control. > link (that represents a hyperlink) - changed from "link" role to no role as it is one of the meta elements and not generally included as part of the page content we consider it to be out of scope for ARIA. > menu type=context - changed from no role to "menu" role its a menu > output - changed from "status" role to no role its not a role=status its may be a generalised live region. > math - changed from no role to "math" role role="math" will map to a math role in Accessibility APIs (if they have one) We think the <math> element will also be mapped to a math role in APIs > table - changed from "grid" role to no role role="grid" is an interactive table, a table by default is not interactive. > td - changed from "gridcell" role to no role role="gridcell" is an interactive cell, a cell by default is not interactive. > tr - changed from "row" role to no role "Rows contain gridcell elements, and thus serve to organize the grid." http://www.w3.org/WAI/PF/aria/roles#row (In reply to comment #12) > When I produced the diffs attached to this bug, I found that they fall into the > following categories: > > > 1) Use of some ARIA property attributes is restricted when a related native > HTML attribute is present. > > 2) Some elements that previously had no default role and allowed any role > simply because the spec did not say otherwise, are now explicitly documented as > allowing any role. Oddly, some remain undocumented though. > > 3) Some elements have much less restrictive sets of allowed roles in the > proposal than in the current draft. In some cases (e.g. <a role=button>) it's > clear how this relates to the rationale based on actual author usage practices. > In other cases (e.g. <a role=scrollbar>, <input type=checkbox role=radio>), > it's not obvious without further explanation how that rationale applies. Are > these things that authors really do? If so, are there examples that can be > cited? I don't think I have ever seen an <a> element used as a scrollbar or a > slider myself, and I've seen a lot of crazy markup. > > 4) Some elements have a more restrictive set of allowed roles and/or new > default roles. For example, embed allows any role in the current draft, but in > the proposal is limited to no role, application, document or image. As another > example, keygen is now not allowed to take any role at all. > > 5) Some elements are about equally restrictive but just different. For example > <menu type=context> changing from no role to "menu". > > > I also noticed the following notable details in the changes: > > 1) Element default roles that are not explicitly documented in the proposal. > > The proposed new ARIA section explicitly lists most of the elements which have > no role by default and can be given any role. However, it seems to have missed > the following: > > a (that does not represent a hyperlink) > area (that does not represent a hyperlink) > caption > command > dd > dl > dt > h1-h6 (with an hgroup ancestor) > img (that does not have an empty alt) > li (with no ol or ul parent) > optgroup > option (not in list of options or datalist) > > 2) Elements that have their default role changed > > These differences seem more individually notable than the others, and may be > oversights in either the current spec or the proposal. They might be worth > extra attention. > > details - changed from no role to "button" role > input type=file - changed from "button" role to no role > link (that represents a hyperlink) - changed from "link" role to no role > menu type=context - changed from no role to "menu" role > output - changed from "status" role to no role > math - changed from no role to "math" role > table - changed from "grid" role to no role > td - changed from "gridcell" role to no role > tr - changed from "row" role to no role -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Sunday, 22 August 2010 06:45:52 UTC