- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 26 Mar 2008 15:10:19 +0200
- To: Lisa Seeman <lisa@ubaccess.com>
- Cc: public-pfwg-comments@w3.org
On Mar 26, 2008, at 12:39, Lisa Seeman wrote: > The rule is: if there is a way to do this in your native language > use that > if you can. > > Roles are for when you can not use the native support such as: If > you are > not in html5 , or have a clickable span and it is too hard to > reengineer or > who - knows what. In a mark-up without the semantic support that > you can > still expose your intent using roles. I think that is clear from the > general > principals > > We hope that eventually, all roles will have native support in all > languages. This specification smoothes the translation and also helps > language designers see what we suggest they include. I see HTML > taking on > many of these semantics as a good thing, but it does not mean we can > just > drop them. I think I'm seeing a tacit assumption that you need to add the landmark because HTML 4 doesn't have them or because some other assumed host language doesn't have them. What the HTML 4.01 spec has or hasn't is completely irrelevant. What is relevant is what existing browsers implement, what kind of changes to existing Web apps are feasible and what kind of browser implementation time-to-market characteristics different solutions have. <div role=navigation> and <nav> are about equally easy to implement in upcoming browsers. From the scripting point of view <nav> is marginally nicer than <div role=navigation>. From degradation behavior point of view, <div role=navigation> is better than <nav> in Firefox 2 and earlier, but <nav> used as a landmark in markup is not disastrous and a script-generated <nav> degrades just fine. As a long-term solution, <nav> is cleaner than <div role=navigation>. These are the kind of considerations that should be weighed. <div role=navigation> and <nav> are both invalid HTML 4.01. You'd be breaking the rules of the old spec anyway. HTML 4.01 doesn't matter at all here. What another assumed host language doesn't have is also irrelevant. ARIA is pitched as a way to retrofit accessibility semantics into existing Web apps. Existing apps are HTML. The other DOM-based language existing apps might be in is SVG. Making ARIA go beyond HTML and SVG is serious scope creep. Whether landmarks make sense in SVG should be weighed against the existing uses of SVG. The landmarks don't obviously make sense for SVG usage, since the landmarks are document-oriented and SVG is graphic-oriented. Even if they do make sense for SVG, it doesn't follow that they should also be introduced into HTML as a second system in addition to HTML 5 container elements. > re email marked "RE: <input type=search> and role=search". > it can be noted that HTML is made by a difrent working group, but > having a > role hear is likely be considered in HTML as there is an overlap and > communication with working group members. That reminds me of Conway's Law. :-( I think we should aim for great built-in accessibility in HTML and author-friendly language design despite working group lines instead of having "accessibility" as a separately developed add-on. > re email marked " Real sites have a disincentive to use banner as > defined". > I agree that most sites will not want to use this, however, it is > better for > the user - such as those with disabilities, and were it might not > get wide > adopting we are sticking to our role - provide semantics for > accessibility > and adaptability - people may chose not to use it does not mean we > should > not give them the option of having it. There's no point in implementors bearing the cost of supporting a feature if the feature isn't used by authors. In this case, it should be easy to predict that the feature will fail to get used. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 26 March 2008 13:11:05 UTC