Re: aria-flowto changes user-agent behavior, which isn't the intended purpose of ARIA

It's probably possible to do that example with CSS. But, I'm not sure why 
tabindex or flowto are necessary either if CSS can handle all situations.

I don't like the link idea, because the content won't always need any 
links. Sometimes it's just static text. I don't think hidden links area 
good way to define things.

You are right that there is overlap with features in host languages, 
although flowto does more.

The aria-flowto attribute has several benefits over other systems, because 
it can link whole containers of elements rather than just chaining 
focusable items:
- it affects the reading order of the document, not just tab key 
navigation
- it generally requires fewer changes even for navigation changes, since 
form controls still tend to collect in group
- unlike tabindex, if new content is inserted into the document that also 
changes navigation, the old and new content navigation order settings are 
unlikely to interfere with each other (e.g. tabindex="5" in both places)
- it fits nicely with current accessibility APIs that have flowto and 
flowfrom relations

Perhaps if there is redundancy but flowto is a better model, the answer 
isn't to kill flowto, but to recommend that other WGs consider it for a 
navigation model in their host languages.

- Aaron





From:
James Craig <jcraig@apple.com>
To:
Aaron M Leventhal/Cambridge/IBM@IBMUS
Cc:
WAI XTech <wai-xtech@w3.org>, wai-xtech-request@w3.org
Date:
12/08/2008 10:28 AM
Subject:
Re: aria-flowto changes user-agent behavior, which isn't the intended 
purpose of ARIA



If the referenced portion is actually in a separate section, but is only 
relevant to a particular spot in the text (a footnote, for example), there 
should be a link, perhaps utilizing the 'rel' attribute. 

If it's not actually a separate section, but it's just a styled to be 
displayed in the next column (a pull quote, for example) then the source 
code order should remain the same and the style should just be defined 
with CSS. 

In either case, I don't see a reason to change reading order or tab order 
for AT.

On Dec 8, 2008, at 1:14 AM, Aaron M Leventhal wrote:

Let's say I ask my screen reader to read the page from top to bottom, but 
there is a sidebar (magazine style). 

How do I use tabindex or nextfocus to indicate to the AT when to break off 
to the sidebar so that it's read at a relevant moment? 

- Aaron 


From: 
James Craig <jcraig@apple.com> 
To: 
Aaron M Leventhal/Cambridge/IBM@IBMUS 
Cc: 
WAI XTech <wai-xtech@w3.org>, wai-xtech-request@w3.org 
Date: 
12/08/2008 09:56 AM 
Subject: 
Re: aria-flowto changes user-agent behavior, which isn't the intended 
purpose of ARIA




But that could result in a different tab order and behavior when assistive 
technology is running than when it is not, or a different behavior between 
different types of AT with varying levels of support for aria-flowto, and 
it could potentially conflict with a host language feature (like nextfocus 
in XHTML 2). I'm still not sure this is a good idea. 


On Dec 8, 2008, at 12:23 AM, Aaron M Leventhal wrote: 

I agree that this is wrong because it goes against the purpose of ARIA, 
but I think it's just incorrectly worded. The text in the spec should say 
something like "aria-flowto recommends a document reading to assistive 
technologies". 

- Aaron 

From: 
James Craig <jcraig@apple.com> 
To: 
WAI XTech <wai-xtech@w3.org> 
Date: 
12/08/2008 08:59 AM 
Subject: 
aria-flowto changes user-agent behavior, which isn't the intended purpose 
of ARIA





aria-flowto changes user agent behavior, which isn't the intended purpose 
of ARIA. 
http://www.w3.org/WAI/PF/aria/#aria-flowto 

If ARIA really needs this, we should move it to section 6.2.3 and make it 
a requirement of implementing host languages. 
http://www.w3.org/WAI/PF/aria/#host_general_focus