Thanks. Fixed now.

http://www.accessibleculture.org/research-files/ozewai2011/basic-html5-aria-screenreaders-presentation.html#%281%29

It’s interesting to look at the comparisons between the browser wars and the ‘screen reader wars’ in terms of behaviors, functionality and esp. interpretation of ARIA-assisted content. I am currently in a situation where I have to make my company’s web app accessible at all costs, including painting over ARIA and other a11y ‘conventions’ to make the thing truly accessible. I know that there is a push for screen reader companies and other tech providers to take more responsibility for their products and I can understand that.

However, I think there is a simple reality here that some of them are simply not able to commit to the kind of quality I would (and our app) need to get things humming. I won’t argue that it is a pain-in-the-you-know-what…but I’m worried that having seen the ARIA behavior adoption, it may be up the web developer community to fill that gap until these Screen Reader companies are ready to step up to the HTML5 plate.

Does anyone have any thoughts on this?

I’m sure other developers are in the boat. We don’t have stats for screen readers or other assistive software. We’re guessing a lot. One reason I love Jason’s site is that at least I can be made aware of what bugs are out there in multiple screen readers.

I don’t disagree with the HTML5 writers’ idea of XHTML2′s <h> tag; for syndication situations it’s brilliant. There was a lot of good ideas in XHTML2 and I see the WHATWG tried grabbing many of them, which I think is good.

Thanks for your second post. I’ve been there Writing, it seems, no matter the medium, can be so often open to (mis)interpretation.

Regarding the ARIA solution, yes, if hard-coded the setting of role and aria-level could lead to problems in browsers/AT that support the HTML5 outline algorithm. I suppose one possibility might be to use JavaScript to add the attributes and set the appropriate value for aria-level depending on the heading’s nesting.

In any case, while I appreciate the opportunity to use explicitly ranked heading elements to support current browsers and AT that don’t do the HTML5 algorithm, and still support JAWS in IE using role and aria-level, it is definitely extra work. I certainly don’t meant to suggest that the dilemma is completely mitigated; only that there is a way out, for now. But who ever said that supporting un-interoperable AT was easy?

I’ve read this article twice again and now I’m even more frustrated.. As you @Jason write as a closing remark – we don’t want to take these decisions!

As for use of HTML5 I still believe that developers should and need to embrace it as the furure (and current) standard. Yes it has grown into an almost mature version and it took some years. HTML5 has lots of benefits, the maybe most important around the document structure; Intentions are good and done right (by all parts) it will be a relief for everyone not to decide where the h2, h3 etc. should go (because semantic structure is set by the new document outline). And it will be easier to re-use content in varying content (for the same reason).

@Jason and Jason M: As for the suggested model using role and aria-level – I guess that would mean that either developer or editor would still have to decide what aria-level a given heading-element should have? But isn’t that exactly what HTML5 is trying to avoid by letting the new document outline take over..?

Regarding HTML5 being the current version or not; I want to advocate HTML5 as the standard people should use from now. Building big solutions for the web is time consuming and expensive. The sites I’m involved in has an average development time range round 6+ months. HTML5 specs are evolving and I feel that not making use of the solid part for the specs would be wrong. Especially the document outline structure, which (from my point of view) is the very backbone of HTML5, would be hard to ignore.. Wouldn’t it be odd to create a solution that would outdate after a short period?

Target segment also matters – most projects I’m involved in are within the public sector and has high focus and demands for accessibility. So every serious issue (in browsers and/or AT) is my issue, and dilemma.

I do not make use of hgroup, mostly because I don’t see the point and necessity, but its not to compare with the document outline structure – which (hopefully) isn’t going to change. That part is so mature that vendors DO need to prepare for its coming, not to say presence..

As a last remark; Big thumbs up for Jason and everyone involved and participating in this blog and similar.. I come here as a web site developer and I try to catch as much information as possible to avoid conflicts between AT and the sites I’m involed in. Hope to succeed in that and I hope that vendors do the same – understand and respect the web as it evolves..

Great suggestion, and nicely solves the problem with JAWS in IE:
<hx role="heading" aria-level="x">

Dilemma mitigated.

Thanks.

Navigation

Perhaps it is time for Freedom Scientific to stop relying so heavily on the off screen model and allow the browser to render the HTML.