#sitemast #skiplinks a:focus,
#sitemast #skiplinks a:focus ~ a {transform: translate(52em);}
#sitemast #skiplinks:focus-within a {transform: translate(52em);}
That’s what I’m now using, with fingers crossed.
]]>:focus-within
in a selector kills the entire selector in IE11. So, yeah. Fun.
]]>I have not, but I dig it, David! I suspect that will appear in my style sheet pretty darned soon. Thank you!
]]>Wrap can wrap your header and nav elements within a div.focuser and the following CSS will reveal the #skiplinks whenever any element is focused within the div.focuser:
.focuser:focus-within #skiplinks a {
transform: translate(52em) !important;
}
I plan on writing more about this technique, as well as some more advanced use cases on my blog “soon”.
]]><h1>
), something I should fix. As for the roles, I try not to assume too much about the tech that will be used to access the site, especially given the wide range of technology available around the world. So for me, explicit roles are worth including. Maybe by the time I redesign again, somewhere around 2031, I’ll be able to drop them…
]]>As far as the appropriate markup for the headings, if I understand it correctly (from reading Jeremy Keith’s HTML5 for Web Designers, Chapter 5, on semantics) it’s fine to have multiple <h1>
s on the page as long as they are “scoped” by a sectioning element (like a <section>
or an <article>
).
Thanks for sharing the responses you’ve received on accessibility. It’s good to hear that there’s value in having the markup in the same general order as the presentation.
]]>Regarding the roles, I would agree with others that you really don’t need them. Unless you expect people to be on older assistive tech. I feel that this has been supported by all major AT for at least 3 years, though others may know more. I would only apply roles manually if the only thing you’re allowed to touch a design with is to add some JS so that you’re adding the roles onto divs/spans via JavaScript, or if you know a major browser doesn’t natively support an element (e.g. Firefox has lacked support for dialog for a bit so manually adding role=”dialog” does help them out some). If you can use native HTML5 elements then do so.
I would advise against adding roles on elements like an unordered list. That can confuse some semantices. It should stick to a nav element.
Of course, adding the roles doesn’t hurt, it’s just something I wouldn’t be adding myself on a new site unless I had a specific reason for it.
]]>Philippe, the recommendations I got (see, for example, this comment from Marco Hengstenberg) indicated that for older-browser support, explicit roles were needed even for elements that should have them implicitly. I also found them in the markup of the sites of people who do a lot of accessibility work, like Adrian Roselli. Given their intent, I feel like they are at least somewhat necessary.
The <h4>
is definitely an error on my part; I let it hang over from the previous design by mistake. Out it goes! Thanks for catching that.
role
values as they are the default values for most elements to which you applied them (and thus redundant). The only place where it is (eventually) justified is for a ul role=navigation
and a div role=complementary
I see in your source code. Spec and HTML validator advise against doing that.
Another thing, your main navigation (nav
) contains an h4
heading, but it is hidden even to screen readers – they won’t benefit from it. Perhaps add a aria-label
?