Accessible interfaces development
Want to test accessibility of your resource? Shut your eyes a bit so the screen looks blurred and then try to click somewhere, enter some text, use some menus or pages. If you’re not convenient using simple actions, then it worth thinking about accessibility.
There are just three principles needed to apply, for something to become accessible. You may bookmark two sites that have recommendations related to the accessible content development and change some workflow to adopt the new model. Upon completing, your page or tool will get to new level of design: they will become both accessible and convenient for any people with most of possible disabilities.
“Accessibility” unites some recommendations, basises and technologies. Following these, we can develop pages and tools that will be easy-to-use for anyone, including those with different disabilities.
Accessible pages at first glance are indistinguishable from “every day” pages, but they are enhanced to be easy to use for anyone: with low sight, hearing, retired ones and even any healthy person with low-speed mobile Internet.
Let’s get a bit into developing accessible interfaces basing on some examples.
What will the usual development process look like?
Let’s say we have some kind of layout made by designer. We want to create a page. If the web page meets all technical requirements and coincides well with the layout, we may think our work finished.
To make web things available to anyone, all that is enough is to insert 3 steps into development process.
We want to build some kind of weather panel that we want to show the weather and prediction for upcoming days.
Process of developing a widget can be split into 4 main parts:
- modal window;
- a widget build.
The easiest one interactive element: elegantly styled and it works very good with JS.
Relevant layout will look like:
It fits the layout well, but if one can’t see a screen well, it may look blurry.
“Basic” button, as a default, makes a blue stroke appear around it. But if one can’t see the color difference between green button and blue frame, how can one distinguish the focus?
So that’s a trick – we are supposed to do something to focus. First of all, focus is not about creating a beautiful style, but about the way how autofocus (and focus) works.
Elements can be in different states, which can be well implemented using some pseudo-classes. Well, three main for us are:
- : hover – guidance;
- : focus – focus;
- : active – click.
It seems pretty simple to done – all we have to do is each element with pseudo-classes and that’s it, everything will be OK. But we got “but”.
Usually, a good designer gives a style guide that contains not only description of elements but also a layout. Via styles, we can set the buttons to focus as we need it to. Elements on blurry screen will look more noticeable for low-sight users, compared to the common blue ring around.
Sadly, layout does not always have all the states. Often we have just 2 of them: normal and hovered.
It’s not enough to be really available, but we may also add the missing states. They differ usually by simply being a bit darker or lighter.
Keep in mind, that accessibility is much more than just development. Accessibility is also about lot of things, like design, content, and so on. so your team have to deal with it.
We won’t think about how buttons should work. w3.org have a dozens of elements with correspondent scenarios of behaviour. It will give you all the needed recommendations on developing available resources.
So, it says that it would be better for button to become active when Enter or spacebar is pressed.
Everything works as needed if default Button tag was used. Using the Enter or spacebar triggers a default click handler.
Below we have a primitive counter, that consists of two buttons and one element that displays the result.
- When “Count” clicked, the value got increased. When “Reset” clicked, the counter resets.
- Using Tab and spacebar, we may ensure that it works the same way.
- To reset the result, we should press spacebar when focused on the second button.
Our buttons now keep focus exactly as needed. Let’s get some more.
Best of all, if applicable, is to use native browser elements. They already support all the needed features and are easy to implement.
III. Screen reader
Look, what happens when visually impaired user who wants to use the widget. He/she can’t see the screen well or at all, so the screen reader becomes the only way for him/her to interact with our tool.
- Turn off the colors to check the screen reader.
- Using Tab to navigate to the first button will make the screen reader say that this object on your accessible web form example is a button. It now will say the name to inform that this button updates the counter.
- But result is not voiced.
- Ok, resetting the result jumping to the second button makes the screen reader says that we got to the button, but it won’t say anything about what does it do. Nobody clicks the button, which he is not sure about.
Buttons still work bad with a screen reader so let’s fix it.
Good news – all we don’t know how to change is probably stated in the documentation.
Let’s get to problem itself.
Screen reader, by default, reads what is inside the button. We have no text in “Reset” button code. Element inside is just an SVG icon.
<use xlink: href = ”# reset”> </ use>
Documents notes that when the button has no text, it’s better to add its description manually via the arial-label attribute.
Adding arial-label with related text, like, “Reset counter”, may solve the problem well. It’s not stated in the documentation, but doing so allows users to get real feedback and find out the counter result.
After button got clicked, the screen reader announces the result of the counter. That’s why accessible website is really accessible: now if we drop this value we will know it even if we can’t see it. That’s exactly what we’ve starved for.
So that’s it: via 3 simple steps, we made our usual buttons accessible.
Want to get more? Stay tuned.
And as always,