We are working to make one of our responsive sites more accessible, but are struggling to get our heads around ARIA as it seems to go against the core principle of separating design elements from the HTML.

For example if an element is hidden in aria one would indicate it as aria-hidden="true". However most visibility is determined by media queries depending on screen size etc.

In other cases elements work completely different based on media queries. So at some sizes aria-haspopup="true" would be appropriate while on other resolutions the navigation is always visible.

Am I missing something, or are we at font tags all over again with this standard? Are we supposed to add / remove aria tags using javascript as appropriate?

  • “WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a technical specification published by the World Wide Web Consortium (W3C) that specifies how to increase the accessibility of web pages, in particular, dynamic content and user interface components developed with Ajax, HTML, JavaScript and related technologies” (Wikipedia) – so seeing that it focuses heavily on dynamic applications, setting those attributes via JS where/when appropriate should not seem that surprising a concept, wouldn’t you agree? – CBroe Jun 25 '15 at 21:54
  • One of its main purposes is to ensure accessibility in “non-linear flows”, such as JavaScipt interaction introduces to a page or app. Because f.e. dynamically showing content, out of the normal “order” of the document (if a normal web page without such JS interactions was read by a screen reader), introduces accessibility issues especially for users that don’t use the medium in a visual way, using JS to set those attributes dynamically makes a lot of sense. – CBroe Jun 25 '15 at 21:57
  • Fair enough. It seems a bit unnatural, but I can work with this. – Kenneth Spencer Jun 25 '15 at 23:17

Actually Kenneth, your question makes a lot of sense, and, yes - tooling for responsive sites is not ideal. I don't have an answer for you, but what I have to say is too long to be a comment...

Consider the following example: You app has a menu button that opens a side drawer using a short sliding animation. Without a11y considerations, your job is easy (lets assume the drawer is on the left and has a width of 250px):

@media ... (min-width: 1000px)
#drawer {
  left: 0;

@media ... (max-width: 999px)
#drawer {
  left: -250px;
#drawer.opened {
  left: 0;

(Not an exact syntax, add your own wizardy for the sliding animation)

To make this accessible, you'd have to do one of the following:

option 1

Don't use aria-hidden='true'. It's generally enough to hide the drawer using visibility:hidden or display:none. Of course, now you need to wait for the end of the sliding out animation to hide the drawer (or you lose the animation).

option 2

Use aria-hidden='true'. You'll have to catch window resize and add / remove aria-hidden='true' when switching sizes (you lose the media query magic).

To sum things up, you're right. There's definitely room for improvement. This is especially true, considering the general shift to move stuff off of JS to keep things 60fps smooth.


You have to use the window.matchMedia function

For instance:

var mm = window.matchMedia("(min-width: 600px)");


var updateAriaHidden= function (obj) {
    if (obj.matches) {
        // set aria-hidden true/false when width >= 600px
    else {
        // set aria-hidden true/false when width < 600px

Using jQuery for instance, you can use the :hidden selector with a custom CSS class to set the aria-hidden attribute dynamically:

$(".toggleable:hidden').attr('aria-hidden', true);
$(".toggleable:visible').attr('aria-hidden', false);

The use of the custom class make it easy to match the elements which would change based on your media queries

Your Answer

