I’ve been working on applying these techniques to my AccordionView widget.

I’m baffled by the fact that when I remove the href attribute, Safari won’t let me focus the element anymore. Yet, in your example it seems to work but different looking (not the safari ‘glow’ effect on focus but a dotted line).

When I put the href attribute back, all is fine in Safari.

Is there something I’m overlooking? I can’t for the world figure it out…

Thank you.

Cheers

Regarding #1: I was motivated primarily by performance. Since there is always a cost associated with modifying the DOM, I figured it didn’t make sense to apply the WAI-ARIA Roles and States in older browsers that don’t support ARIA. However, for those that do, I did design the browser sniffing to account for future versions of FF and IE. Additionally, in my experience using ARIA, I haven’t found it has reached a level of maturity where I can apply the roles and states and it will just work out of the box. For that reason, I prefer to only provide functionality when I have tested it and am confident that it will work for the user.

Regarding #2: I tested using JAWS 9, and found that with the Virtual Buffer off (required for ARIA and the keyboard functionality to work), JAWS would in fact read the value of the “href” attribute. For example, when the Firefox tab receives focus, JAWS reads: “Firefox tab http:// ….”. For that reason, I removed the “href” attribute. I don’t see any problem removing the attribute, as the anchor itself is only there for the C-Grade browser experience when the user is building a TabView from existing markup. In an A-Grade browser, the anchor element doesn’t play a functional role after the TabView has been instantiated.

- Todd