Posted by bowersox on June 25, 2011 at 2:31pm
Should Drupal be using the aria-label property on any form fields?
So far our FAPI accessibility efforts have focused on making sure there is always a Label attribute. We make sure the Label is connected to the form element by ID. And we allow module developers to choose the location of their label (before, after, hidden off-screen, etc.)
At this point, is assistive technology using the aria-label property? Should we be using it in any circumstances when we already have an on-screen or off-screen label? My cursory reading of the ARIA aria-label spec suggests the answer is No. But I wanted to raise this question so we have the right accessibility strategy for D8 and FAPI.
Comments
@brandon aria-label, or
@brandon
aria-label, or aria-labelledby, should only be used on non-native controls. Generally speaking native elements and attributes (such as title=) should be used where possible.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Can we use this in place of invisible titles?
Right now we are doing stuff like this:
<nav role="navigation"><h2 class="element-invisible">Main menu</a>
<ul>... menu ... </ul>
</nav>
I came across this slide today, which suggests using
aria-labelfor that title: http://webaim.org/presentations/2011/ahg/ariahtml5/landmarks2<nav role="navigation" aria-label="Main menu"><ul>... menu ... </ul>
</nav>
I really like this idea. I'm not a big fan of invisible text all over the place (I like to call them easter eggs), especially headings, where we can't always have fine-grained control over using the proper heading level. This approach really appeals to me, and while I assume we didn't do this initially in Drupal 7, because of the validation problem, I wanted to ask: Are any other reasons or issues that would prevent us from using this technique?
Thanks :)
Hi Jacine The technique that
Hi Jacine
The technique that you have described works, but removing the heading means removing structural navigation ofr users whose technology doesn't support ARIA landmarks or HTML5 semantic elements.
I'm not saying that I am completely opposed, I'd prefer the headings not be there for my own convenience, but I don't know what users are currently using. We've never really had a UA/AT support matrix.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Thanks Everett ;)
Does the fact that D8 wont release in like 2+ years buy us any hope? Looking at this table, support looks pretty good to me, with the exception of Window Eyes 7.5: http://www.html5accessibility.com/tests/landmarks.html
How long do we support client technology?
That's really the question. IE6 is a terrible example of technology that was supported way too long. Now if everyone were using NVDA or Orca then this wouldn't really be a concern as we can just explain to folks how to upgrade their browsers.
However, many folks are using JAWS or Window-Eyes which are both expensive for people to purchase:
http://en.wikipedia.org/wiki/Window-Eyes
http://en.wikipedia.org/wiki/JAWS_(screen_reader)
I've certainly heard of cases where people can only afford to upgrade their screen readers every 5 years. If that's the case then technically we we would be safe knowing that Window-Eyes 7+ & Jaws 10+ could support it.
Unfortunately, people & habits take longer to change. If you've been navigating the web using headings (in best cases) for a decade, it would be quite a mental shift to start to re-learn how to pull out the relevant content from a site quickly.
However the community needs to come to a decision about this.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I'm less concerned about
I'm less concerned about changing the UI paradigm (no heading navigation of page structure, only of content structure). It is the cost issue, but really more the reality of technology currently in use / anticipated to be in use when D8 ships.
I really don't have a sense of what would be a good data source for this decision.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
UA/AT support matrix
We probably should start thinking about what a UA/AT support matrix should look like - and it should be reasonable. We are trying really really hard to make our front-end code the best it can be. As a result, we've dropped IE6, and will hopefully drop IE7 support. This will end up being a pain point for some people temporarily, but for the 80% use case, it will be a big win.
The decisions we make for Drupal 8 will be with us until ~2016 from a support standpoint. I know it's hard to predict the future here, but we should keep that in mind and maybe try to solicit advice.