OK - I’m probably missing something here. Surely somebody using a screen reader is using it for everything on the computer, not just web browsing? So having to close their familiar assistive technology to use something else to browse that won’t work with their familiar software is helpful how?
I don’t think that’s OT, but I have a warped sense of that…
It’s a good question – but I wasn’t so much using it as an example in that sense, as it is to show that if they would bother paying attention to the markup, they wouldn’t NEED any of this ARIA BS… It’s often like they fail to leverage the what has existed in HTML for hooks since TBL came up with it! Of course, the same could be said of the majority of people writing websites who seem blissfully unaware of how to use numbered heading tags, don’t realize there are more tags than TR and TD that can go inside TABLE, and never even heard of SHOCK label, legend or fieldset.
It also proves a very good point – normal applications don’t have ARIA assigned to them, and they work just fine with said third party assistive tech…
HTML was developed to say what content IS, and to allow you to mark sections with headers, links with anchors, and all the other semantic meanings so that the user agent could best determine how to present the content within the capabilities of the target device – be it tickertape, Phone TTL, daisy wheel printers, Commodore VIC=20, videotex terminal, braille, whatever. ALL the needed hooks for such things are already present in it – making ARIA nothing more than redundant bloat, or a lame excuse on the part of third party developers and the people writing websites not to bother paying attention to the markup itself.
Though with the total garbage people have been vomiting up and calling HTML the past decade I can’t entirely blame the makers of screen readers for it…
Crusty: I had no idea there was a screen reader in Opera. A screen reader with navigation and all?? Or a read-out-loud program?
Re ARIA: accessible Rich Internet Applications. That means, when your HTML isn’t representing a document, but an application, accessibility that’s built-in quit working. XHTML2 introduced aaa:roles to fix that. Let the author writing the application indicate what roles the HTML elements were taking within the app.
This later got split into ARIA. When used correctly it turns a broken widget into something you can use with a screen reader. Since you’re not going to stop widgets, they had better be accessible.
Technobear: yeah, your controls are usually the same system-wide, which is why I’ve poo-poo’d FireVox and ChromeVox (though I guess if you’re using a “chromebook” thing it doesn’t matter cause the thing’s not really a computer anyway).
Kind of in-between in a way – it doesn’t say anything until you hit V, but it uses the browsers default keyboard navigation to get around. When something is outlined from keyboard nav it’s also treated as focused/selected (despite only being outlined instead of inverse color)… so when you land on a page you hit ‘next header’ to select the first topic area, and v to read it. Then next and v – once you get to a section that you’re interested in you start selecting through elements. It’s not as usable as JAWS, but again I was more pointing at it to show that the hooks already exist in the markup.
Which is a hefty part of my issues with it – but I think the whole ‘internet applications’ nonsense for normal web pages is pointless bloat and WORSE for accessibility; see why I think XML+Application is pointless BS and the only XHTML I think there’s any point to was 1.0 as text/html.
That’s basically /fail sorry to say Jason. Yeah I know it has been around for years. I have known about Opera Voice for about 4 years and use it occasionally, and think it is handy when I have bad days. Give that to people who actually use AT, they’ll laugh. In the real world that is like saying you can use the standard keyboard for all programs, but for MS Word you have to use a white keyboard with no labels set in Devorak. Most people would find an alternative. There has been push back to Google making their apps work with ChromeVox junk versus coding correctly, but this is gettin off topic.
Basically a text-to-speech program with basic keyboard navigatiblity. If you have heard of ClaroRead, take that, with keyboard hotkeys with the ability to jump to various elements, as Jason said in #20.
Does role=“navigation” have any use? Seems like a handy one to me.
I think Steve was only discussing the OP’s code here. Role=“navigation” is indeed handy, so long as (like other landmarks) it’s used sparingly per document.
Nav already had “navigation” as a role built-in, for the readers (like NVDA) who already understand the native roles, but it’s still good to manually add the role for now (or when we have navigation but no HTML5 nav tags).
Or did something have “navigation” on it in the code I missed?
The way I read it, steve was saying that ARIA roles are mostly redundant, but I may have read wrong. Obviously there are other ways to signal navigation, such as a (perhaps hidden from view) heading element that announces it. Not sure which is better, or if screen reader users really care. Accesskeys seem viable too. It’s all a bit much for my widdle bwain.
steve was saying that ARIA roles are mostly redundant
Yes, on elements who were recognised before roles were ever introduced: checkboxes are known to screen readers, so telling a screen reader that a checkbox has a role of “checkbox” is redundant.
Roles have use when you’re using an element who either doesn’t have a role, or doesn’t have a role matching what you’re using it for.
Landmark roles, though, are different. They are completely new: there were no “banner” or “navigation” roles before. You had to either rely on skip links or a hidden header stating “main navigation” or, usually, the first list you run into that starts with links like “Home” etc.
With landmarks, provided they are on the page and you the user are aware of them (if your screen reader is just set to automatically start announcing stuff about the page on page load), then there’s a key you can hit at any point on the page, so no matter where you’ve navigated to on that page already, that brings up all the page landmarks. It’s like your own skip link list, which you can call at any time (not just when you run into them at the beginning) that are always the same (the names of the landmark roles are set in the specs for the most part) no matter what page you’re on.
To me, this all has way more benefits than accesskeys, which will differ between pages. Though accesskeys can be fine for sighted keyboarders using Opera, but lanmark roles will work in all other major browsers and in the newer versions of major screen readers.
Ah, Marco Zehe has made a blog post about “when to use the application role”: http://www.marcozehe.de/2012/02/06/if-you-use-the-wai-aria-role-application-please-do-so-wisely/