[whatwg] Question about allowed and descendants

[Aaron Leventhal]

http://dev.w3.org/html5/spec/Overview.html#the-ol-element

> Categories:Flow content 

> Contexts in which this element may be used: Where flow content 
 is expected.
> Content model: Zero or more |li 
| elements.


Is there a conflict between these things? It seems that the  and 
 elements allow flow content.
On the one hand, that seems to allow many kinds of descendants, such as 
child lists. However, the content model says that only  children are 
expected.


What about nested lists, like this?

Apples
Oranges

Seeded
Navel




I would think that's allowed. So, what kinds of content are allowed 
inside of  and ?


- Aaron

Re: [whatwg] Early feedback on header association algorithm

[Aaron Leventhal]

IMO it's not worth all the extra code and confusion to write a special 
table (but not inner table) ID getter.


- Aaron

On 12/6/2008 7:55 AM, Henri Sivonen wrote:

On Dec 5, 2008, at 17:09, Aaron Leventhal wrote:


How about node.getElementByIdInSubtree?



It's not sufficient to get an element in a subtree. What's needed is 
getting a cell in the same table--filtering out nested tables.

Re: [whatwg] Early feedback on header association algorithm

[Aaron Leventhal]

How about node.getElementByIdInSubtree?

On 12/2/2008 4:07 PM, timeless wrote:

On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal<[EMAIL PROTECTED]>  wrote:
   

Maybe there is a deeper problem if copy&  paste doesn't work right because
of IDs?

Or maybe there should be a node.getDescendantById() method?
 


maybe, but not with that name.

  Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 seconds)
  Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 seconds)

the wikipedia links are confusing enough

http://en.wikipedia.org/wiki/Descendant links to:
http://en.wiktionary.org/wiki/descendent
which has an also link to http://en.wiktionary.org/wiki/descendant
which has a 'US' audio file

So the web says that '-dant' is favored 2:1 over '-dent', which is a
fairly bad margin considering the spelling errors we've seen in
html/http.

I'd sooner see Node.getElementById and risk the confusion of it
returning fewer nodes than Document.getElementById.


   

Re: [whatwg] Early feedback on header association algorithm

[Aaron Leventhal]

Maybe there is a deeper problem if copy & paste doesn't work right 
because of IDs?


Or maybe there should be a node.getDescendantById() method?

I don't know. It just seems odd to implement something special here for 
that.


- Aaron

On 11/22/2008 3:06 PM, Henri Sivonen wrote:

On Nov 22, 2008, at 15:50, Henri Sivonen wrote:


On Oct 29, 2008, at 19:43, Aaron Leventhal wrote:


1. On this part:
  "If there is a header cell in the table 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#concept-table> 
whose corresponding |th 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-th-element>| 
element has an ID that is equal to the value of id, then assign the 
first such header cell in tree order to the data cell. "
I don't want to implement a special local table only 
getElementByIdInTable. I'd rather have this reworded to something like
"If there is an element in the document with a corresponding ID (via 
getElementById) equal to the value of /id/, and it is a header cell 
in the current table, then assign it to the data cell."



While implementing a special lookup method is something that one 
would want to avoid, using getElementById has two problems:


1) It makes the association brittle under copy and paste. Consider a 
case where a page author creates a table with internal id references 
and then a maintainer duplicates the table and edits the contents of 
the copy table. Now the table coming later in the document order is 
inaccessible but this brokenness is unobvious to a person who isn't 
accessing the page with AT.


2) It makes the reporting of table relationships not form a coherent 
table. Consider a program that instead of allowing the user to 
traverse the table an arc at a time tries to pull all the arcs from 
the accessibility API and reconstruct the table in its own process 
space. If there are arcs between tables, the result is not a table 
structure at all.



Oops. I didn't read the text I quoted properly. Sorry. #2 was already 
dealt with.


However, wouldn't testing if the cell is in the current table already 
go a long way towards the complexity of implementing 
getElementByIdInTable?

[whatwg] Early feedback on header association algorithm

[Aaron Leventhal]

1. On this part:
"If there is a header cell in the table 
 
whose corresponding |th 
| 
element has an ID that is equal to the value of id, then assign the 
first such header cell in tree order to the data cell. "
I don't want to implement a special local table only 
getElementByIdInTable. I'd rather have this reworded to something like
"If there is an element in the document with a corresponding ID (via 
getElementById) equal to the value of /id/, and it is a header cell in 
the current table, then assign it to the data cell."


2. The larger part of algorithm is upside down for our needs. I see a 
use case for providing what headers are associated with a cell, but not 
the other way around. Typically an AT will want to know what labels or 
headers to present to a user when a user navigates to a cell. Therefore, 
I wish the entire algorithm was flipped and tells us what headers are a 
match for a given cell.


3. The one piece of information we do need when we are on a given  
is whether to expose it with ROLE_ROWHEADER or ROLE_COLUMNHEADER in our 
GetRole() implementation. If scope isn't "row", "rowgroup", "col" or 
"colgroup" then we'll need to base that on the position in the table. It 
seems fairly obvious if the  is in an edge (but not corner) 
position, but other cases are less obvious.


I haven't gone through the algorithm in fine detail yet, mostly because 
of comment #2. We'd have to turn the algorithm inside out in order to 
evaluate it.


- Aaronj

[whatwg] Ressurecting a11y thread [was Re: Video, Closed Captions, and Audio Description Tracks]

[Aaron Leventhal]

Has anyone put any further thought on what to do about captions for Ogg?

We've started to throw some thoughts together here:
https://wiki.mozilla.org/Accessibility/Captioning_Work_Plan

We could use some help from individuals who understand the area of video 
and captions. The problem of deciding what to do for captions in  
or specifically for Ogg does not appear to be simple. I'd appreciate it 
if someone could prove us wrong.


- Aaron

Silvia Pfeiffer wrote:

Sorry to be getting back to this thread this late, but I am trying to
catch up on email.

I'd like to contribute some thoughts on Ogg, CMML and Captions and
will cite selectively from emails in this thread.


On Oct 9, 2007 5:22 PM, Henri Sivonen<[EMAIL PROTECTED]>  wrote:
   

On Oct 8, 2007, at 22:12, Dave Singer wrote:
 

I don't think we can or should 'climb inside' the content formats,
merely have a standard way to ask them to do things (e.g. turn on
captions).
   

I agree. However, in order for the HTML 5 spec to be able to
reasonably and pragmatically tell browsers to ask the video subsystem
to perform tasks like "turn on captions", we need to check that the
obviously foreseeable format families (Ogg in the case of Mozilla
and, apparently, Opera and MPEG-4 in the case of Apple) are able to
cater for such tasks. Moreover, browsers and content providers need
to have a shared understanding of how to do this concretely.

 

This should all be out of scope, IMHO;  this is about the design of
a captioning system, which I don't think we should try to do.
   

I think the captioning format should be specified by the video format
family. However, in this case it has become apparent that there
currently isn't One True Way of doing captioning in the Ogg family.
In principle, this is a problem that the specifiers of the Ogg family
should solve. In practice, though, this thread arises directly from
an issue hit by the Mozilla implementation effort. Since the WHATWG
is about interoperable implementations, it becomes a WHATWG problem
to make sure that browsers that implement Ogg for  and content
providers have the same understanding of what the One True Way of
doing captioning in Ogg is if the HTML 5 spec tosses the captioning
problem to the video format (which, I agree, is the right place to
toss it to). Hopefully, the HTML 5 spec text can be a one-sentence
informative reference to a spec by another group. But which spec?
 


Ogg indeed currently has no preferred means of specifying captions.
Usually it happens through a separate srt or ssa or similar file and
the player makes sure to display the captions correctly.

I just had a look at the W3C DFXP format
(http://www.w3.org/TR/2006/CR-ttaf1-dfxp-20061116/). It looks rather
similar to CMML, lacks the hyperlinking functionality, but has
stylesheet and formatting support in it and more
subtitle/karaoke-specific functionality. I believe it would be
straightforward to define a media mapping for DFXP into Ogg should we
decide that DFXP is the way forward. Similarly, it would be rather
simple to define a media mapping for any of the anime subtitle formats
mentioned above.

Somewhat orthogonal to the discussion about subtitles is the use of
CMML. Yes, it is possible to use CMML in its current specification as
a superset of a srt-type sutitle format. However, the "description"
element would then need be interpreted as the caption, which is
somewhat of a misuse. I actually see captions and CMML as orthogonal
concepts - CMML provides hyperlinks and machine-readable textual
annotations in a timed manner, while captions provide formatted text
for users to read.

=

On Oct 10, 2007 3:03 AM, Maik Merten<[EMAIL PROTECTED]>  wrote:
   

Benjamin Hawkes-Lewis schrieb:
Actually I wonder if it wouldn't make sense to have an attribute for
media elements specifying a URI for a file containing Timed Text. These
externally stored (not embedded in a media file) captions would be
codec-agnostic and could be used to reuse the very same set of captions
for e.g. differently encoded media (Ogg, MPEG,
Generic-Codec-Of-The-Season, ...).
 


In the above described cases of DFXP, srt, ssa or CMML, each one of
these are text documents that can potentially live independent of the
video file n a server ("externally stored"). In fact, apart from CMML,
there is no defined mapping for Ogg of the others as yet.

   

As a side note I like the idea of captions which are more than just the
usual stream text. Imagine a newsreel with timed "Would you like to know
more?" links. Given that HTML5 is usually viewed in browsers that
implement at least a non-empty subset of HTML I imagine it should be
possible for the browser to layer something div-equivalent over the
media elements supporting captioning and pipe the HTML captions into it
(with caution, imagine a caption itself recursively embedding a video).
 


That is exactly what CMML provides to Ogg: timed textual annotations,
hyperlinks out of a vide

Re: [whatwg] Should enter be mapped to click?

[Aaron Leventhal]

3.4.1.7. Interactive content, paragraph 3:
   

Thanks! Small typo:
instead of being activating the element directly,
Extra word "being"

- Aaron

[whatwg] Should enter be mapped to click?

[Aaron Leventhal]

Now that tabindex can be used on any element to make it focusable, it makes
sense that it should be possible to trigger a click on those elements with the
keyboard.

Opera maps Enter to click. As far as I know, other browsers only do that for a few 
elements like.

What do people think? Should it be spec'd?
At least the spec should say what elements map enter to click now. Except for 
perhaps  and a few form controls, I don't see why some should and 
others not, though. Maybe it should be a blacklist?

- Aaron

Re: [whatwg] ARIA

[Aaron Leventhal]

I don't know if you've seen the recent Accessible Rich Internet 
Applications  draft?  (There's also a 
primer at .)  It describes a 
number of standard states that can be added to custom controls.  
Rather than potentially fitting multiple values into a reldata 
attribute, it defines a host of attributes beginning with "aria-".  
Example:


Foo

I believe a number of script libraries (Dojo for example) plan on 
supporting ARIA.  Firefox has some ARIA support already.
Thanks for pointing to WAI-ARIA. Just to clarify the status, both Dojo's 
Dijit library and Firefox 3 fully supports the current draft on both 
Windows and Linux. There are still being tweaks made in screen readers 
to support the outer edges of the ARIA widget semantics as well as ARIA 
live regions (for areas of the page that change but are not really 
widgets, such as an updating scoreboard).

More info on who is working on ARIA support in the FAQ here:
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ#Who_supports_ARIA.3F

- Aaron



The current HTML 5 draft doesn't mention ARIA anywhere.  Perhaps it 
should clarify the relationship (or non-relationship as it is at 
present), even if it's only a brief mention in section 1.1.


Regards,

Dave

Re: [whatwg] activedescendant in viewport (Re: scrollIntoView jarring?)

[Aaron Leventhal]

I think if there is an attribute like this which also scrolls for you, 
then it should be called activedescendant, not aria-activedescendant. I 
don't see a problem if HTML 5 wants the attribute without aria- to drive 
browser behavior. In that case perhaps it should style the active 
descendant to it is active somehow.


In general it's easier to explain ARIA if there are some consistent 
principles, such as, it doesn't drive browser behavior. It just allows 
the JS developer to report what they did. And since the widgets also 
need to work in older browsers that don't support ARIA, it's better if 
the aria- attributes maintain that rule.


Otherwise, without that rule, it really is a slippery slope. First we 
have aria-activedescendant scroll for you, so why not show it is active 
for you? Why shouldn't aria-disabled actually make the item disabled? 
Etc. etc. Pretty soon we're implementing the widgets for the author and 
none of it works most browsers.


- Aaron

Re: [whatwg] Are unfocusable elements focusable with tabIndex="-1".

[Aaron Leventhal]

So how do I know if this has been registered as a pending issue that 
will be fixed in the spec?


I checked with Opera and they also do tabindex="-1" makes anything 
focusable.

So the spec is out of line with implementations.

- Aaron

Re: [whatwg] Are unfocusable elements focusable with tabIndex="-1".

[Aaron Leventhal]

As I mentioned in the WebKit bug report just now 
(https://bugs.webkit.org/show_bug.cgi?id=7138):


The WhatWG spec appears to be wrong, in that it says:

 A negative integer specifies that the element should be removed from the tab
 order. If the element does normally take focus, it may still be focused using
 other means (e.g. it could be focused by a click).

It should also say that a negative integer makes elements focusable but not
tabbable, whether they are normally focusable or not.

IE certainly does do that -- they just don't show focus visually, which 
is really a section

508 mistake on their part. The app always needs to show where the focus is.
For IE the author's workaround is to put in an onfocus handler and use 
element.style to show focus.


- Aaron

[EMAIL PROTECTED] wrote:

Hi,

An incompatibility between the implementation of tabIndex between IE and
Firefox caught my attention because Webkit is now implementing tabIndex as
well. [1]

In IE, unfocusable elements with tabIndex="-1" are still not focusable. In
Firefox they are focusable. Focusable elements stay focusable with
tabIndex="-1" in both browsers.

The HTML 5 spec specifies the IE behavior, if I read it correctly. I would
prefer the IE implementation as well, simply because that would make the
implementations compatible sooner.

greetings,

Sjoerd Visscher
http://w3future.com/weblog/

[1] https://bugs.webkit.org/show_bug.cgi?id=7138

Re: [whatwg] ARIA

[Aaron Leventhal]

Jim Jewett wrote:
I think the question is more about how the HTML elements themselves 
interact.

For example,  elements should probably be interpreted by default
as  because that is part of the semantics of tr.

In some cases, the default mapping will also depend on other
attributes.  (  vs)

Ideally the specification would give a complete list of such defaults,
because otherwise there will be at least a few disagreements.  For
example, it looks as though  should *not* have aria-role=list, but
that isn't something I would have guessed from the names.
   
In general these are great questions. The question as I understand it, 
should the spec spell out which role & properties you get naturally with 
an HTML element, so an author knows if they even need to override them 
with ARIA in the first place?


Do you mind asking this question on the wai-xtech list/ You can get 
subscribed to on an individual request basis -- just email me and I'll 
help you get on it. If you don't want to spend a lot of time, then 
please at least send your feedback to [EMAIL PROTECTED] 




The next question is what to do when an author explicitly uses an aria
attribute other than the default.  For example, it is fairly common to
hook javascript to a checkbox so that it acts like a command button.
Therefore



should probably be treated as having both roles, but
aria-role=presentation (or even a parent with
aria-role=childrenArePresentational) should probably remove the
default aria-roles
   
This one is simpler. ARIA properties override the built-in semantics. 
You can use |role| on any element, such as  and it will override 
the natural role of the element. Therefore role="button"> will be reported to assistive technologies as a button. 
The same thing applies to properties. ARIA properties have the last say 
when they conflict with the natural properties of an element. Overriding 
one property with ARIA does not affect the other properties on an 
element. These simple rules were found to be the most effective. There 
are a lot of sensible concerns. I've drafted a FAQ here with some more 
info, which I think addresses most concerns: 
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ
A Best Practices Guide and Primer are under development for authors. I 
am also working an implementors guide for user agents. Let me know if 
you want to see that.


As aside: I noticed you refer to role as aria-role. The role attribute 
is the one ARIA attribute that doesn't need "aria-" as a prefix. It's a 
special attribute that is intended to address more than accessibility -- 
it's been argued already and unlikely to change because of currently 
shipping software.


- Aaron

Re: [whatwg] ARIA

[Aaron Leventhal]

ARIA doesn't really overlap with HTML, because ARIA only reports what 
a JS developer is using elements for.
So ARIA semantics should not affect  behavior. Any code for dealing 
with ARIA markup should be strictly in the accessibility API support 
code (MSAA/IAccessible2/ATK/AT-SPI/UI Automation/Universal Access).


This seems like a poor idea from the point of view of authors actually 
using the markup correctly as they will have to use special 
accessibility-API aware tools to inspect the effects of their aria-* 
markup.
We've addressed most design concerns like this (which are generally 
legitimate concerns) in the ARIA FAQ.

http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ

The goal was to have apps that still work normally in legacy browsers. 
This means all the code to implement widgets needs to be in the JS of 
the page.


On the other hand for the "landmark" roles which specify semantics but 
not behavior, I would agree that sticking with HTML elements is a better 
approach. Even if there is associated behavior for them, such as a 
hotkey, they will degrade well to older user agents.


- Aaron

Re: [whatwg] ARIA

[Aaron Leventhal]

James Graham wrote:

Dave Hodder wrote:
The current HTML 5 draft doesn't mention ARIA anywhere.  Perhaps it 
should clarify the relationship (or non-relationship as it is at 
present), even if it's only a brief mention in section 1.1.


Unfortunately a brief mention is insufficient as aria functionality
overlaps substantially with HTML functionality and so processing
requirements for aria-in-html need to be carefully considered (so we can
answer questions like "how does  affect the
outline algorithm"). This has not yet happened.


Okay, so I can speak to this. I developed first browser implementation 
of ARIA -- the one in Firefox.


ARIA doesn't really overlap with HTML, because ARIA only reports what a 
JS developer is using elements for.
So ARIA semantics should not affect  behavior. Any code for dealing with 
ARIA markup should be strictly in the accessibility API support code 
(MSAA/IAccessible2/ATK/AT-SPI/UI Automation/Universal Access).


A div need not affect the outline algorithm, etc. any more than a div does.
Thus it should not be complicated to mention ARIA in the spec.

- Aaron

Re: [whatwg] Scoped tabindex proposal

[Aaron Leventhal]

tabindex="-1" doesn't just remove items from the tab order. It also 
makes items focusable via mouse click or script, which is important when 
designing custom container widgets like spreadsheets, etc. via 
Javascript. In fact any negative value does it.


Don't try to overload the tabindex attribute. First, the browsers 
currently optimize it knowing that it's an integer. Second, the scoping 
is orthogonal. Third, magic values are less readable. It's voodoo.


- Aaron



Simon Pieters wrote:

Hi,

Currently if you want to use the tabindex to change the tab order you 
mostly have to specify tabindex on all links and form controls prior 
to the area you want to modify the tab order, because otherwise that 
area would be before all prior elements in the tab order, which in 
most cases isn't wanted. Therefore there's a need to scope tabindex 
somehow.


So here's an idea. A new value for the tabindex attribute, "scoped". 
Here's an example:


  The following links should be focused in the order which the link 
text indicates:

  first
  
   
second
forth
   
third
fifth
  
  last

The table itself is not in the tab order and is not focusable.

I'm not sure if we need another attribute or something for this 
instead as .tabIndex is a long and not a DOMString. Or perhaps we 
could say that all elements that have a tabindex attribute is a 
scoping element, so that authors can use tabindex="-1" on the table 
instead.


Here's a pointer of where this (or something similar) is called for:

  http://accessifyforum.com/viewtopic.php?t=6034

Regards,
Simon Pieters

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

I'll think about it what you say about the checkbox. Honestly it hasn't 
come up before. You're right in that if images are turned off then this 
example is no  longer accessible to sighted users.


While screen readers aren't the only important thing, they are 
important. If we put an alt text there then I find it likely that the 
screen reader will speak redundant, confusing information, at least in 
Firefox 1.5  I'll have to think about how we can avoid that.


Thanks for bringing up the point.

- Aaron



Jim Ley wrote:

On 14/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:

I hadn't considered putting an alt text on it, because the image's
function is described by the role itself.


It's got nothing to do with it's function, you've got an image in the
page, to be accessible a user has to be able to find out what the
image is - unless it's purely decorative where you could have an empty
one - but this is a functional image - so it must have an ALT, there
is no discussion


Does the image for a checkbox using a standard html need an alt text?


The standard HTML checkbox is not an image, it's a checkbox...

So, I'm not sure why you stopped looking after
that


Because you claimed something was truly accessible, when you'd not
made the first step of ensuring images have ALT text, say, here's an
example which makes  an image used as a checkbox accessible to some
screen readers, and if you put in a lot of other work you could make
it accessible to other people would've been okay, but you didn't you
chose to claim it was truly accessible.


It seems like something else is bothering you about my message.


Just the all too common claim of accessibility authors not actually
increasing accessibility just moving it to a different group having
problems.


In any
case, I'm only here as a fellow colleague providing food for thought. I
hope that's not a problem.


Oh definately not, your work is very useful!  Just don't make the
mistake of over-claiming what you do, the examples are not accessible,
they aren't unfortunately.


The core is, accessibility is important and
no doubt there are places where whatwg does things better,


I don't think the what-wg does a good job of accessibility at all,
there are some good ideas certainly, but there's also a lot of badness
due to the degrading to a whole heap of script that's required in a
number of areas.

Your work on Role is very good, and I'd certainly encourage you to
stay participating in the what-wg.

Jim.

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

Jim,

I hadn't considered putting an alt text on it, because the image's 
function is described by the role itself.

Does the image for a checkbox using a standard html need an alt text?

In any case, more effort on better examples is being put into Dojo, 
where the code will actually be used. This example is here to show the 
concept. Therefore, while I may not be sure that an alt text belongs 
there, the code serves as a simple example to show how the authoring is 
done for this technique. So, I'm not sure why you stopped looking after 
that -- this adds accessibility for keyboard users, screen 
reader/magnfiier users and can improve accessibility for alternative 
input users.


It seems like something else is bothering you about my message. In any 
case, I'm only here as a fellow colleague providing food for thought. I 
hope that's not a problem. The core is, accessibility is important and 
no doubt there are places where whatwg does things better, and places 
that can benefit from some of the knowledge built into the WAI roles and 
properties. Whether the role attribute itself becomes supported or not 
is only one way to get there.


- Aaron



Jim Ley wrote:

On 14/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:

What browser/screen reader are you using?

You need at Firefox 1.5 or later and Window-Eyes 5.5 or later or JAWS 7
or later.


I'm not using a screen reader, accessibility is about not requiring a
particular technology...  Or did I miss a memo?

Cheers,

Jim.

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

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" <[EMAIL PROTECTED]>

To: "James Graham" <[EMAIL PROTECTED]>
Cc: "WHATWG" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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:
 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




  

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

Anne,

I said at the start of this thread that the best solution is to have 
widgets that are already accessible. However, we don't have a standard 
for that at the moment.


We agree that accessibility experts should not be needed in order to 
make content accessible. It's not only big companies that can do this. 
For example, the open source widget library Dojo is adopting this. 
That's something everyone can use, for free. The authors are getting the 
widgets and accessibility for free, but without this technique Dojo 
couldn't provide that.


Remember that this does not just apply to HTML. Roles apply to SVG as 
well, and any other type of XML-based renderable markup with 
accessibility gaps. I see it becoming a superset of what's needed for 
full accessibility of rendering markup standards.


In any case, there is a general agreement that it's better to have 
accessibility built into predefined widgets that are easy to use. If 
whatwg + xbl becomes the accepted standard and we don't need roles, 
great! One of of my suggestions was the we work together to make sure 
that everything addressed by the roles and properties is addressed by 
whatwg. For example, liveregion, which has properties for describing the 
type and relative importance of various mutations within that container. 
Without something like liveregion in whatwg, you can't make AJAX apps 
accessible. Regions of the page that change but don't get focused will 
not be understood by assistive technologies, unless there is some markup 
to describe it.


- Aaron


Anne van Kesteren wrote:

On Mon, 14 Aug 2006 06:36:40 -0700, James Graham <[EMAIL PROTECTED]> 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.



--Anne van Kesteren

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

Jim,

What browser/screen reader are you using?

You need at Firefox 1.5 or later and Window-Eyes 5.5 or later or JAWS 7 
or later.


- Aaron

Jim Ley wrote:

On 13/08/06, Aaron Leventhal <[EMAIL PROTECTED]> wrote:

So we already have truly accessible DHTML widgets that are
key navigable and usable with 3rd party tools such as screen readers.


Could I ask where these are discussed?  Because things like:
http://www.mozilla.org/access/dhtml/class/checkbox
are certainly not accessible to me (there's a non purely decorative
image that without alt text for example)  Please don't say truly
accessible, when it clearly isn't.

How much trouble would it have been to just go .alt="checked"
"unchecked" ?  I stopped looking beyond that.

Jim.

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

So you are saying this should be mapped to assistive technologies via 
the CSS3 "appearance" property or via special values in the class attribute?


The role attribute currently describes behavior, and is added so that 
users with disabilities know what the behavior for a given element is, 
according to well-known semantics. CSS is supposed to be for 
presentational. In your scenarior, will there be any way to easily know 
whether one of the items in the class attribute describes the behavior 
is purely presentational? Otherwise, both authors and machine processors 
will be easily confused by it.


I like the role attribute because it's already usable in Mozilla, to 
make accessible web applications. What's the advantage of using 
class/appearance instead, if there is no browser already mapping this 
information to assistive technologies?


- Aaron

Matthew Raymond wrote:

James Graham wrote:
  

Matthew Raymond wrote:



[...] where a proper CSS presentation for the users primary media is
not available [...]
  

This is almost always the case on the real web.


   Yeah, the web masters are so lazy that they can't be bothered to add
accessibility via CSS, but they'll be working overtime putting in |role|
attributes using the correct predefined values.

/me rolls eyes.
  
Roll your eyes all you want but when you get bored, perhaps you'd like 
to try thinking about the relative difficulty of the two tasks instead



HTML + Role:
| 
|   Any checkbox label
| 

HTML + CSS3-UI:
| 
|   Any checkbox label
| 

   But this is really just a distraction, since I generally support
using class instead, which itself can be used to style an element using
the "appearance" property.

  
:-) For many widgets it is entirely obvious what their role attribute 
should be (if it walks like a duck and quacks like a duck it's a duck). 



   How is that? What other W3C approved values are there other than
those in the |role| working draft?

  
So adding this information to the semantic layer (i.e. not CSS) is easy. 
Furthermore, people who make common widget toolkits can add 
accessibility information at the toolkit layer (see e.g. [1]) so authors 
don't need to work very hard.



  Correct, although I would point out that toolkits can be redesigned to
support whatever becomes a standard.

  

   I don't see a significant difference between |role| and predefined
values for |class|.
  

Oh and I'm allergic to predefined class values :)


   I would suggest a strong antihistamine whenever you use a microformat.
  
Indeed there are, I believe, a number of problems with microformats 
associated with their use of the class attribute (e.g. I remember a 
discussion some time ago in which it turned out that microformats must 
use globally unique classnames)



   I see nothing in the HTML 4.01 spec that prohibits class names from
having colons, nor does it explicitly forbid the use of namespaces, so
nothing stops us from using namespaces in class names. (You could argue
that the namespace URL has to be declared, but I don't see how |role|
avoids this problem.)

   Meanwhile, the spec for |role| _REQUIRES_ name spaces for anything
that isn't directly defined in the working draft. Therefore, it is
actually more restrictive for microformats than using |class|. So I
really don't understand your argument.

   Yes, there are those who oppose the use of namespaces for
microformats, but near as I can tell, they oppose namespaces in all
circumstances, including in XML. The |role| attribute would not escape
their wrath, due to its namespace requirement.

  

Re: [whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

There are a lot more roles than what you listed, and they are all mapped 
via desktop accessibility APIs such as MSAA and ATK to the assistive 
technologies. So we already have truly accessible DHTML widgets that are 
key navigable and usable with 3rd party tools such as screen readers.


If you're interested in what roles are supported, check out the docs:
http://developer.mozilla.org/en/docs/Accessible_DHTML#Simple_and_complex_examples

You have to do something like  or 

There is no other standards-based way to make these types of widgets 
accessible in a web page today. I don't think it's a narrow use case. 
Look at the huge numbers of websites that are trying to become more like 
desktop applications.


- Aaron



Matthew Raymond wrote:

Aaron Leventhal wrote:
  
Firefox has support for making dynamic web applications with custom JS 
widgets accessible, via support for xhtml:role and aaa: properties. If 
anyone would be interested in taking a look, I would welcome feedback.



   What Firefox is doing for DHTML accessibility has a very narrow use
case. It applies to DHTML widgets, that are not bound to fallback markup
using XBL, where a proper CSS presentation for the users primary media
is not available, and where the CSS3-UI "appearance" property doesn't
provide a proper value. I suspect that many DHTML widgets, however,
won't necessarily have a corresponding predefined |role| value, which
means |role| essentially becomes just another vector for microformats.

   I don't see a significant difference between |role| and predefined
values for |class|. For instance, I believe Dublin Core specifies
predefined |class| values, so it's not like there's no precedence for
it. The only difference is that |class| doesn't explicitly state that it
can be used for such purposes.

  
I have a specific question: what about adding the role attribute to 
whatwg specs?



   I don't see any sufficient benefit from it. I'd rather see a
clarification of how |class| can be used.

  
However, I thought I'd ask anyway because the role attribute does fill 
some niches:


1) [accessibility] in SVG



   I don't understand. Could you provide a use case? BTW, how would this
even apply for HTML, which has no namespaces?

  
2) roles that no specs today have, which provide important accessibility 
functions, such as liveregion for AJAX accessibility (perhaps we should 
try to synchronize the 2 sometime)



   I'm not following you here. This sounds a lot like microformats.

  

3) ability to fix [accessibility] in JS apps that exist today



   There are only a small number of supported values for the |role|
attribute. Most of those are covered by tags in HTML5:

 <--> "main"
 <--> "secondary"???
   <--> "note"
 <--> "navigations"
  <--> "banner"???
  <--> "contentinfo"

   So, the only things really missing are tags for "seealso" and
"search". Note that  may cover "seealso". It might be that
"seealso" doesn't have a sufficient use case to give it an element
separate from . I think we probably need some way to
semantically identify searches, though.

   I can't really understand "banner". Is it a header or an ad? If it's
for ads, I suspect it won't be used. Why tell people something is an ad?
They can just make and extension to filter the ads out.

   Secondary is another think that's hard to understand. It seems to be
in between  and "note".

   So, generally, I don't see |role| providing significant improvements
over existing markup in the HTML5 spec, especially since you'd have to
have less semantic elements to act as the parents for each |role|
attribute...

HTML5:
| [...]

HTML + |role|:
| [...]

   Now, which is more readable? Clearly the first example, especially in
a complicated web design when you're looking for the _CLOSING_ tag.
Elements are clearly smaller and better, and since namespaces are
required for user-defined |role| values, the actual number of |role|
values that can be used in HTML is limited to those listed in the spec.

  
4) ability to create new custom roles -- this is still under development 
(at the moment it uses RDF, but I believe the group will consider XBL 
moving forward)



   How does this differ from using XBL with |class| and other existing
HTML attributes to implement microformats???

  
5) The role attribute allows us to specify additional semantics without 
conflicting with older browsers



   So would using classes with predefined semantics, and styling with
classes is very well supported on CSS-enabled user agents.

   I agree that there are some styling issues with the new HTML5 markup,
seeing as they're all block-level elements, and my understanding is that
unknown elements

[whatwg] Dynamic content accessibility in HTML today

[Aaron Leventhal]

Firefox has support for making dynamic web applications with custom JS 
widgets accessible, via support for xhtml:role and aaa: properties. If 
anyone would be interested in taking a look, I would welcome feedback.


In Firefox 1.5 the role attribute had to use the xhtml2 namespace. 
However, Firefox 2 will allow the role attribute in XHTML 1.x.
See "XHTML Role Attribute Module":  
http://www.w3.org/TR/2006/WD-xhtml-role-20060725/


I have a specific question: what about adding the role attribute to 
whatwg specs?


I know Hixie mentioned that he would prefer the element tag itself 
always specify the role, rather than using a role attribute which can 
conflict and override that. XBL was going to be the solution for 
creating custom widgets, which I prefer myself. In an ideal world, I 
think we'd be able to just create new custom widgets via XBL and define 
that accessibility there.


However, I thought I'd ask anyway because the role attribute does fill 
some niches:

1) a11y in SVG
2) roles that no specs today have, which provide important accessibility 
functions, such as liveregion for AJAX accessibility (perhaps we should 
try to synchronize the 2 sometime)

3) ability to fix a11y in JS apps that exist today
4) ability to create new custom roles -- this is still under development 
(at the moment it uses RDF, but I believe the group will consider XBL 
moving forward)
5) The role attribute allows us to specify additional semantics without 
conflicting with older browsers


For more info --

Here are some docs for those interested in comparing what we have with 
whatwg:
Developer docs & intro: 
http://developer.mozilla.org/en/docs/Accessible_DHTML


For those who have w3c member access (apologies for that):
Roles: http://www.w3.org/WAI/PF/Group/GUI/roleTaxonomy-20060809/
States: 
http://www.w3.org/WAI/PF/Group/adaptable/StatesAndProperties-20060809/


- Aaron