I’ll give this one a try. I’ve been using some basic landmark roles in my pages, and a few ARIA attributes in forms… further nothing more.
The term “conflict” brought about a bit of confusion. Do they mean that no other role should be applied other than the one(s) listed? That doesn’t sound right. If not, what constitutes a conflict being that multiple roles can be assigned? Only roles that directly conflict such as putting a “document” role on an li element?
I believe they are saying if you have an element with a default semantic role (example, the <button> element having a “button” role) and then, I dunno, manually giving it a “presentation” role, the UA may choose to honour just one if the two are really incompatible.
You can have multiple roles, and multiple attributes, but I believe the document you linked to says IF there is a conflict, then you need to fix it (remove the conflict).
Should I steer clear of using attribute selectors in my CSS based on roles? I vaguely recall some versions of IE not supporting unrecognized attributes so my concern would be an older version of IE ignoring some of my css rules.
IE6 does not understand ANY attribute selectors.
IE7 understands attribute selectors. Also remember IE has special names for a label’s for (htmlFor) attribute and elements’ class (either class or className) attributes. It has small bugs like foo[bar]+somechild breaking.
IE8 still goofs a bit in tables but mostly supports attributes.
I have seen multiple ways to create a navigation menu. What I’ve been doing is creating a ul with li’s that contain a elements and then applying styles to them. However I recently saw an example where the li elements themselves had an href attribute eliminating the need for the anchor element. With HTML 5 and it’s focus on semantics, I’d like to use a nav element and just anchor elements with the menuitem role applied. What are your thoughts?
So far as I remember, the “href on non-anchors” thing was an idea from XHTML2, which was scrapped because existing browsers wouldn’t understand/correctly use it, and HTML5 is all about backwards compatibility. Instead, HTML5 has decided to let authors wrap the normally-inline anchors around block elements, which gets around one of the reasons people wanted href attributes on non-links. I dunno if you can wrap an anchor around a table’s trs, but you can wrap it around a header or a div.
The true intended/planned semantics of HTML5 have not reached any actual browsers yet (it is in many betas such as FF4b and possibly the new Opera 11 has some). Who benefits the most directly from semantics? Other computer programs and users of accessibility technology. Currently I dunno which-all screen readers knows what a <nav> is and the ones who don’t recognise it are just seeing the <ul> tags inside. My understanding of <nav> tags is to wrap those <ul>s who are not just lists, but specifically (primary) navigation lists. A user hitting “l” key for all lists on the page is getting all lists… a user whose reader first reads out landmarks can choose to go specifically to the navigation landmark, regardless of whether that landmark was set on an actual ul or on a div containing many primary navigation uls.
As a note, the idea is that the role of “navigation” will be added as a default semantic role of the <nav> element. Currently this causes NVDA to think there are two navigation lists if you also manually add the “navigation” role to a ul already wrapped in a <nav> tag. The only browser I know of who will have these default roles for some HTML5 elements is the upcoming FF4 stable release.
If you are writing HTML5 and using ARIA, you may be building a site for the future. It will not work nicely today with current browsers and screen readers. This is why I haven’t used anything of HTML5 beyond the nice doctype on any production pages. Another thing to remember is while AT is slowly getting a hang of both ARIA and HTML5, they are reliant on the accessibility layer of the browsers (some like Chrome haven’t had any at all, unless the latest latest release changed this) and then of course users have to update their readers. Some readers cost a lot, or were received from a school or government program and won’t be updated. So when JAWS doesn’t see <header> tags and their contents in Firefox at all, it’s a problem even though JAWS12 (the latest release) fixed that. Lots of users may still be using JAWS 9 or 10 (and some may be stuck on version 6 or 7 and therefore are stuck with IE6 for the most part… another reason to maybe consider supporting IE6).
Another issue to keep in mind with ARIA is that so far as I know, only screen readers are getting this useful information (mobiles are possibly going to be able to use these roles in the future though, and that sounds pretty cool). Sometimes I think I have a page with a bunch of lists and menus, and I want to point out the primary navigation with an actual header tag stating so.
Like when there are site menus and product menus, I’ll call them that.
This can let users of any type of linear browsing mode skip having to view the first few links to figure out what the menu’s about. If the page is really full/cluttered, it may even benefit sighted users with graphical browsers.
Hope this gives you some ideas. I don’t know what you’re building or who you are targeting it at, so my advice might be off-base for you. Also, a lot of it is my opinion and possibly some badly-outdated information.
Anyone working on HTML5 spec, ARIA spec, browser AT layers or AT software, would be highly appreciated if more better information could be added or corrected???