Assistive software and HTML5 elements

[adh32]

I'm curious to know something about how assistive software is most likely to handle known children of unknown HTML5 elements, like headings in an <hgroup>. Is a failure to understand the parent element likely to cause child elements to be ignored?

Not that I want to start throwing HTML5 things around my site; just curious.

[rguy84]

I think <hgroup> is one big step backwards for accessibility. Unless something with it will be altered, all examples I seen are:

<hgroup>
  <h1>My Cool Company</h1>
  <h2>Our Motto</h2>
</hgroup>

Or

<hgroup>
  <h2>Blog post title</h2>
  <h3>Post meta data</h3>
</hgroup>

The h2 in the first block and the h3 in the second should be paragraphs not headers. It breaks what a heading does, which is give hierarchy to a page/document, in my opinion.

One thing I think hgroup could be cool for would be allow browsers to create an outline of the page. I think Opera does this already. However if you could make the outline, you would need id's to show which heading is a child to what. But wouldn't just adding a new attribute to <hx>'s be cleaner? Yes! Therefore hgroup is useless.

[deathshadow60]

One of the rules of HTML is that unknown tags are to be ignored. It's why the content of <SCRIPT> was placed in HTML comments and <NOSCRIPT> were not -- older browsers that didn't know SCRIPT or NOSCRIPT would ignore both tags -- the content of SCRIPT in <!-- --> ends up ignored, while the noscript tag is also ignored, it's content showing as normal DATA. (and why you are supposed to have a block level container INSIDE noscript!)

Things that don't know what HTML 5 is will just ignore it -- though IMHO that's probably for the best since I think it's all a bunch of pointless garbage setting coding practices BACK a decade or more. It's HTML 3.2, pretending the concepts and improvements of STRICT never actually existed.

HGROUP and changes to the grammatical rules of heading tags being a PERFECT example of this -- As Ryan said, it just screws up heading tags even worse than they already are; Shocking given how SIMPLE the use of heading tags should be...

But with people ignoring the syntax and even purpose of tags and vomiting up HTML 3.2 with either a 4 tranny or 5 lip-service attached to it, it shouldn't be all that shocking this new specification was tracked through a pile. The only people "excited" about 5 being those who never embraced strict or separation of presentation from content, those who fall for the "but it's newer" trap because they're so green Granny Smith is jealous, and of course those trying to sell new books or new versions of browsers.

... any developer who actually understands the reasoning behind STRICT or separation of presentation from content should take one look at HTML 5 and lose their lunch. There's a reason I have ZERO plans to migrate past XHTML 1.0 Strict for the foreseeable future.

[adh32]

I'm inclined to agree with you, for the most part, about what seems to be a very slack and poorly developed "standard". As I mentioned above, I won't be using such tags in my site any time soon.

But I'm curious to know what the early adopters of the new "parent" tags like figure, nav, and hgroup might be doing to accessibility.

[rguy84]

It all comes down to what AT a person is using. At the time being, hgroup and figure should act like a div thus ignoring them, and nav as a ul. Now I have heard older versions of JAWS muck up on nav. However I heard this from somebody who isn't the best JAWS user and the page was slightly wonky anyhow.

[rguy84]

Looks like my outline idea is being worked on: 4.4 Sections &mdash; HTML Standard

[Stomme poes]

You'll want to follow Jason Kiss' website. Here's an example of some tests he's done with HTML5 and ARIA.

JAWS 11 has a pretty nasty bug: if the user is using it with Firefox, everything inside <header> tags is ignore entirely. This is not what is supposed to happen; it's a bug. What's supposed to happen is if the browser doesn't know what <header> is, fine: it ignores it, internally assigns it as some J Random Inline and may or may not apply styles to it (most browsers will, IE won't unless they are created at least once using document.createElement(new element)). However the content inside is text and images and whatnot, and the screen reader should still know what to do with text, because the browser does.

Specifically regarding the <video> element, when you add the controls attribute, Dragon Naturally Speaking isn't able to get ahold of those yet last I heard. Some people are using <video> tags without the controls attribute and are building them all with Javascript, so they can manually add more control for keyboard, adding roles, and maybe text-to-speech software (not sure actually how one writes JS for T2S).

I'm avoiding the new elements for two reasons: it still seems to screw up ARIA roles when HTML5 elements are present but not with HTML4 (this is likely because HTML5 is adding default roles to elements as we speak, and AT is still catching up), and because scripting is required to get IE to do anything useful with the new elements.

I think in a few years (2 or 3) your question will be answered with "Which version of browser and which version of screen readers/other AT are you talking about?" because it'll depend.

[AussieJohn]

Because I love adding my 2c to old threads, here it is

I went to a Web Standards Group meet up here in Sydney a short while ago where we had Craig Sharkie talk about HTML5, which inevitably brought up some lacking accessibility love. Silvia Pfeifer (http://gingertech.net/) spoke about HTML5 video and also brought up the lack of accessibility of the controls in many browsers/assistive technologies. I do believe she mentioned Mozilla are working on this though (because ultimately it is the browser's responsibility to make sure that controls are made available to the assistive technology.

Also heard Steve Faulkner & Bruce Lawson talk about aria roles (and general HTML5 accessibility), while aria roles aren't implemented properly in a lot of places yet, these are things in the works at the moment.

Regarding headings in HTML5, I tend to think that when they are used in the correct way (probably hgroup aside, though I could see potential uses for it) they could be more helpful. For example, when you have an article listing on a blog, does it *really* make sense for the article headings to be h2 or h3 inside of the listing page. Probably not.

Of course I understand what people are saying, the headings are supposed to give a document outline. I think at the moment, because we are at the cusp of the technology being adopted, the implementations are a little bit lacking. The current parsing algorithm for it is fairly rudimentary, a new one can't just look at the headings, but also needs to look at the context. And that is what it's all about in the end, the context. The article heading is a h1 for the article in the listing, because in the context of the article, it is the most important heading. In the context of the entire web page, the h1 that appears in the site header (which would likely be the first <header> that is marked with the aria "banner" role) would be the most important.


Slightly Off Topic:
Not sure if Jaws 11 is any better than its predecessor, but 10 isn't all that much to write home about. (and I'm being very nice here).

[Stomme poes]

Not sure if Jaws 11 is any better than its predecessor,

UPGRADE

I'm using 10 which at least doesn't screw up with <header> in FF (but then, I'm still using FF 3.6x).

"No JAWS 11 in 2011!"

I've been thinking of upgrading to 12 this year actually

[AussieJohn]

Should upgrade Firefox first :P
v6 is stable, v7 is in beta channel and rocking out.

[ralph.m]

v6 is stable

Every time I close FF6 I get a message trying to explain why Firefox crashed. And when I start up again I get a message that "This is really embarrassing ...". The only embarrassing thing should be all these stupid messages.

[AussieJohn]

I remember I went through a phase on my macbook when Fx 4 came out where I had a similar situation. I think I cleared out a bunch of addons and maybe even created a new profile to get rid of that particular issue.

I tend to run the latest version on my home mac and work (win7) and the latest beta for both Chrome and Fx on my home (win7) machine. Apart from the occasional addon not working on Fx it's not too bad. (I get around the addon issue by having Addon Compatibility Reporter installed)

[ralph.m]

Nice tips, AussieJohn. Thanks for that.

[Stomme poes]

What I ended up doing was

on the Winblows machine at work (where anything can break and I don't care) I installed all the plugins I use except Web Visum (forgot my password, it's on the Linux box) and then upgraded to FF6.

So far, most things seem to work, which is good (even my minor plugins). Although, FF on Windows isn't the same as FF on Gnome.

So now I'm backing up my .json bookmarks file so I can do a clean install of FF6, but not 100% sure plotsing the .json file back in will mean FF will automatically use it, because those are backups, not the mail file (which I can't seem to find anywhere... old search engine posts talk about an html file and I don't seem to have that).

[AussieJohn]

Isn't there an import/export functionality in the Bookmarks Manager?