Thanks, Hans. It is a sad current state of affairs, but based on browser and AT progress over the past few years with ARIA, I’m remaining optimistic. And yes, definitely open to collaborating on improving the situation.

Thanks. I need to focus on smaller research projects!

Thanks, too, for noting the JS/cookies issue with commenting. Have removed the offending plugin. Commenting no longer requires JS or cookies.

I can appreciate your position. I prefer to not concern myself with bugs in AT or browsers where they prevent me from using certain technologies. In this case, the proposed workaround or “best approach” for tree views works now and *should* continue to work into the future, barring the introduction of new bugs. Granted, I don’t think it’s the best tree view approach, so I guess if one wanted to build that, then they’d have to put up with the effects of the bugs. Like so many of the technical accessibility choices we make, there’s a judgement call.

I’m working on a multi-part guide to ARIA at the moment, so when I get to this topic, I will definitely link to your article. Super useful stuff, as usual.

(Off-topic: Your comment instructions should mention that your website insists on support for JS and cookies to post a comment. It’s annoying that it requires them; more so that it is not known before posting.)

My opinion at this point is that while it’s good that you found something that “works” somewhat okay in current browsers and AT (which is what anyone building these things today in a setting demanding utmost accessibility needs), if I were building a tree for the future I would rather build it in the ideal way, with the assumption that the bugs (and yeah I see VO’s issue with links as absolutely a bug) will be fixed… even though this can be a dangerous assumption if you don’t know you’ll be keeping that page updated.

Actually, my bad I phrased that incorrectly. I meant that the presence of parent with the ARIA role=”dialog” was announced in a newer versions of VO (a la Mountain Lion) but not my version in Lion using Safari 5.1.3. This seems to be just because of better support for this ARIA role in a newer version of the Mac OS. I need to remind my self that ARIA is a work in progress, so support is improving (and changing all the time).

“when you talk about focus mode you are talking about forms mode, right? I found the use of the two terms a little confusing in the beginning but if this is the case – then thats fine.”

Yes, forms and focus mode are the same thing. I’ve found that JAWS tends to refer to forms mode, while NVDA tends to refer to focus mode.

“So this negates somewhat the need to use role=’application’ – which for me is a good thing, as I see it more as problematic to support and also difficult for SR users to understand and navigate…”

Yes!

“I know that you haven’t covered VO but I wonder if the behavior is the same? I am guessing it is but there is no buffer used with VO IIRC which would mean that the net result that don’t have to add role=”application” to a widget either for it to work with VO and make the child elements focusable, right?”

VO does not use a virtual buffer, and seems to automatically permit direct keyboard input to elements that need it, based on how the element is mapped to the accessibility API. As for making child elements focussable, this depends on the element. Elements that aren’t natively focussable still need to be made focussable for Safari/VO, e.g. using tabindex, to be put in the tabbing order. How they behave in ARIA widgets is another story and depends on their construction and how keyboard interaction is managed (via scripting). I’m still trying to sort this out myself

“In some exploration I did very recently on a colleagues’ ARIA test cases the use of role=’dialog’ would trigger/enable focus for newer versions of VO (a la Mountain Lion) but not the version in Lion/Safari 5.1.3.”

What do you mean by focus in this instance? I’d be interested to play with the examples: do you have links? There are certainly some major differences in support for ARIA widgets between Safari/VO in earlier versions and the latest version. I’ve found this to be the case with tree view widgets, for example, about which I hope to write something “soon”

Cheers.

A couple of things, when you talk about focus mode you are talking about forms mode, right? I found the use of the two terms a little confusing in the beginning but if this is the case – then thats fine.

I also liked really liked your point about role=”application” and the presence of ARIA roles triggering forms mode within JAWS and giving focus to the children of an element with an ARIA role present. So this negates somewhat the need to use role=’application’ – which for me is a good thing, as I see it more as problematic to support and also difficult for SR users to understand and navigate (as of time of writing due to poor UA implementation).

I know that you haven’t covered VO but I wonder if the behavior is the same? I am guessing it is but there is no buffer used with VO IIRC which would mean that the net result that don’t have to add role=”application” to a widget either for it to work with VO and make the child elements focusable, right?

In some exploration I did very recently on a colleagues’ ARIA test cases the use of role=’dialog’ would trigger/enable focus for newer versions of VO (a la Mountain Lion) but not the version in Lion/Safari 5.1.3.

Anyway, these are all the trials of working with new technologies – and thanks for your insightful research.

I’m not sure I agree with the analogy with select form controls, which have quite a distinct behaviour and don’t themselves permit other interactive content within them. The ARIA select role is itself an abstract role, so can’t be used. Of all the roles, button does seem the closest fit.
The question for me is to do with what exactly user agents should do with elements set with a button role. Should the element acquire all characteristics associated with an actual button element, for instance flattening all nested interactive content to string text? I don’t get this from the ARIA spec for the button role. It seems to be how at least WebKit behaves, whereas FF and IE both pass nested links in an element with a button role to the a11y API, all the while enabling user-triggered actions on that element.
I’m not sure what’s possible or feasible with the introduction of new roles in ARIA.next. Depending on a clarification of what user agents are expected to do with elements with the button (or other) role, it may be useful to consider new roles of some kind to fill those gaps that exist between what ARIA currently covers and what the APIs permit/expect.
Thanks for your comment!