Re: note and navigation are redundant with HTML5 <aside> and <nav> and other emails,

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