- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Sun, 4 Apr 2010 21:17:24 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: HTML WG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>, Shelley Powers <shelley.just@gmail.com>
hi Jonas, If new interactive elements such as form controls are included in the spec, I would hope that they are implemented in browsers to be accessible to people with disabilities, as yet that has not occurred. I don't think that the spec currently provides detailed advice or requirements on how accessible implementations are to be achieved, I am unsure the HTML5 spec is necessarily the place for this information. Even when all the elements in HTML5 are supported by browsers and AT, there will still be an important place for ARIA in HTML5, as there are many features of ARIA that plug gaps in HTML5 one example is "live regions" another is landmark roles and another is the many roles provided in ARIA that do not have a corresponding HTML5 element or attribute. (e.g.s alert, dialog, scrollbar, status, tab, tabpanel, tooltip, treeitem etc) Furthermore, until native controls of any type are styleable to suit developers desires, they will continue to just make things out of elements that suit their visual styling needs and so many natively available controls will still not be used in some situations, as developers will prefer custom controls. Again, in these cases ARIA makes the difference between a control being usable or not by people with disabilities. Even when ALL elements are stylable to suit developers needs, they will still create custom controls that are not part of HTML5's tool set, so again ARIA will be useful in helping to make these controls understandable for AT users. I don't see any friction between ARIA vs native features, the friction is between custom UI libraries vs native features. I don't have a strong opinion on the correctness of using one over the other. if the native feature suits the developers needs use it over an ARIA enabled custom control, if not use ARIA enabled custom controls. If the native controls are not accessible use ARIA enabled javascript UI controls that are. If native features are missing or not optimized to provide the most useful information use ARIA to augment the accessibility information provided. with regards Stevef On 2 April 2010 20:24, Jonas Sicking <jonas@sicking.cc> wrote: > On Thu, Apr 1, 2010 at 12:40 PM, Maciej Stachowiak <mjs@apple.com> wrote: >> >> On Apr 1, 2010, at 12:01 PM, Shelley Powers wrote: >> >>> This discussion is become circular, evidently most people disagree >>> with me. That's fine. I don't agree, but will take my arguments >>> elsewhere. >>> >>> Most of my proposals were about removing these so-called "semantic >>> elements". If the co-chairs want to close these proposals, since no >>> one agrees with me, that's fine too. >> >> The Chairs are very much interested in seeing the level of support or >> opposition for this proposal, and the other similar proposals for removing >> elements. That would be useful feedback for determining the next action. >> >> So far, my read on this discussion is that a number of people disagree with >> the proposal, some have expressed concerns without taking a firm stance, and >> no one besides Shelley has voiced support. So far, I have not seen direct >> comments on the other proposals. >> >> We will be monitoring the ongoing discussion. > > To be clear, I feel the same way about the change proposals for > ISSUE-90, ISSUE-91, ISSUE-93, ISSUE-95 and ISSUE-97 as I do for > ISSUE-96. I.e. that removing semantic elements and attributes is bad > for accessibility, even when ARIA can be used to add similar or > equivalent semantic meaning. > > I'm definitely interested to hear what people with more accessibility > related experience than me think about this. > > I believe Steven Faulkner said that he didn't want any other > "controls" removed from the spec, which I would take to encompass at > least ISSUE-97. But I'm interested to hear his and others feelings > regarding the other change proposals too. > > / Jonas > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 4 April 2010 20:18:17 UTC