Understanding Success Criterion 1.4.4 | WCAG 2.0 AA

Geplaatst op 5 juni 2016 door Gerdt Brouwer

For many of our customers we have to make the sites according to the WCAG 2.0 AA standards. Personally I think it is a good thing but some criteria are not defined easily or are incomplete. To pass the test, this one gave me a small headache in finding all the real criteria.

WCAG 2.0 : Zoom up to 200% using resolution 1024×768

The official definition is :

Content satisfies the Success Criterion if it can be scaled up to 200%, that is, up to twice the width and height. Authors may support scaling beyond that limit, however, as scaling becomes more extreme, adaptive layouts may introduce usability problems.

The pain is that mostly it is left out that this criteria must be met when having the resolution on 1024×768. Ouch, try that and you will notice almost every website will change because they are responsive, meaning also your responsive site should meet this criteria.
The first problem is that all the content visible at 100% should also be visible at 200% meaning you are not allowed to hide content on mobile.
The second problem is that your responsive design must be accessible with a keyboard only and, I guess, most developers do not test this.

The most common solution, still, is the hamburgermenu on mobile. But be aware that this menu should give access to all the content showing on the default site but also to make it understandable for screenreaders.

Creating a hamburgermenu isn’t a big deal where on click a div is shown with the menu-items :
hamburgermenu voorbeeld wcag aria

and roughly styling it with :

So, when zooming in with 200% at 1024×768 you’re browser will show this menu instead of the main menu there was before.
Showing the same menu items and there shouldn’t be a problem?

In this example the word menu is shown, but often it is only the hamburgerline, like <a href=”#”></a>
All People using a screenreader will hear is “link end link” and find themselves wondering if they are missing something.
Another mistake is the href=”#”. Though technically correct HTML people who use a keyboard can not access it because there will be no focus on the menu.

Collapsable menu

Since we use a hamburgermenu, the menu-items are not visible by default and the <a href=”#”>Menu</a> doesn’t make the user aware he/she has to click to get access to the menu.
We can simply solve this using Aria-labels, in this case aria-controls=”navigation” and aria-expanded=”false” where aria-expanded has to be set to true when the menu is opened.

The correct HTML would therefor be :
Use a button and style that one as a hamburger menu. If you really can’t use a button you can use code like this :

with a small javascript that will set the correct value of aria-expanded and show the menu-items.

Role=”button”

When you don’t use a button but for the other solution add role=”button” to the div otherwise the screenreader will not read the arialabels.
Also don’t forget to set tabindex=”0″ since a div is normally not focusable.

Sources:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html

Making Accessible Links: 15 Golden Rules For Developers

Gepost in categorie: TechTalk, WCAG 2.0, Web guidelines

Reacties

Plaats reactie zonder facebook account

Anoniem