[whatwg] Dynamic content accessibility in HTML today

Aaron Leventhal aaronlev at moonset.net
Mon Aug 14 11:09:53 PDT 2006


I'm not at all arguing against having the better, more full-featured 
elements available in whatwg. I'm not saying that roles should subsume 
anything happening here.

I'm suggesting something else, more like:
1) Use the role and state documents that will be public drafts soon, to 
find gaps in your set of elements. If those semantics aren't available 
in your set of fully functional elements then it's worth thinking about. 
By all means provide authors with something easier that they'll want to 
use -- that is certainly better.
2) Consider supporting the role attribute because it is now in xhtml 1.1 
and will allow for backwards compatibility with stuff already happening 
at Yahoo, IBM, AOL, Dojo and others are doing.

- Aaron

And by all

Andrew Fedoniouk wrote:
> ----- Original Message ----- 
> From: "Anne van Kesteren" <fora at annevankesteren.nl>
> To: "James Graham" <jg307 at cam.ac.uk>
> Cc: "WHATWG" <whatwg at whatwg.org>
> Sent: Monday, August 14, 2006 6:48 AM
> Subject: Re: [whatwg] Dynamic content accessibility in HTML today
>
>
> | On Mon, 14 Aug 2006 06:36:40 -0700, James Graham <jg307 at cam.ac.uk> wrote:
> | > But XBL works with ~0 assistive technologies and is presumably going to
> | > be complex to implement properly. Whilst, in general, I agree that
> | > having elements used in the correct way to provide semantic information
> | > is desirable, I think that adopting a technology that is already
> | > implemented and proven to solve real problems is a better approach than
> | > waiting on a complex future specification to be finished and implemented.
> |
> | So a while ago I posted
> | http://annevankesteren.nl/2006/06/accessibility-ideas some of my thoughts
> | regarding role=""... Basically, I don't really see authors taking extra
> | steps to make things accessible. Accessibility should just be an integral
> | part of the language, otherwise I don't think it will work. For authors it
> | will seem that without role="" their custom widgets will work so there's
> | no real benefit in adding it unless you work for some big company that
> | hires a few "accessibility experts" who tell you to add it.
> |
>
> 100% agree.
>
> I would like to remind here one more thing:
> the golden principle of good management is to use/create
> set of motivations rather than use of enforcements and proclaim of good wishes
> of any kind.
>
> Practically in HTML/CSS this should mean following:
>
> Say some  UA will have extended set of "behaviors" implemented.
> (behaviors here correspond to word "dynamic" in DHTML)
> Behavior is that entity which really gives some meaning to the
> 'role' attribute. If behaviors (as a mechanism) will be designed to use
> role attributes then anyone will use it.
>
> Think about popup menu implementation:
> <menu> element and its behavior engine can be designed to
> threat as a menu item *only* element
> having say [role="menu-item"] attribute defined (or some other predefined 
> element like LI).
> In this case 1) accessibility layer will be able to interpret it easily and
> 2) authors will be naturally motivated to use the role.
>
> Andrew Fedoniouk.
>
> More on one possible menu/role implementation:
> http://www.terrainformatica.com/index.php/?p=8
>
>
>
>
>   



More information about the whatwg mailing list