Google is indexing the web with mobile-first strategy. There is nothing special about it when we remember our own internet usage – a mobile phone as our 24/7 companion. At the same time we also have to remember that mobile phone can also be the first and only device people use to access internet. Especially when not only thinking about western part of the world. Some people do not own a computer and their mobile phone is the only way of getting online.
Therefore we must also think more about how to make the web accessible for the mobile users. WCAG 2.1 update brought some long needed improvements and it’s a start.
Semantic HTML elements may be much more accessible than their ARIA imitations
Don’t use ARIA (accessible rich internet applications API) if you can use an HTML element that gives you accessibility out of the box. That seems a simple rule to follow. Need an input that have known minimum and maximum values and can only change in steps, like for example volume control? Then use input type range, right. Simple and quite accessible. But how will we implement the fancy styling for all browsers then? Shadow DOM prevents us to style it as our pretty design wants us to. What is the next step then? Well we have to drop the native HTML input type range and make our own.
So first rule of ARIA can quickly be ignored. Our design was approved and when we start to explain that it is not possible to implement it in every way and in every browser we are forced to make our own “slider”. And it is totally doable – with JavaScript and ARIA we can add on accessibility features to our “all-div” or “all-span” widget that can then be styled as required. Adding keyboard interaction takes some time but not a big issue, we just have to cover all patterns that “native slider” has and manage the focus and we are done, right?
Checking accessibility tree seems to be working perfectly, then running some tests with assistive technology like screen-readers. Running desktop ones first, as we develop on the desktop and it just a click away – done and working as planned.
We made sure the design is mobile-first, right, and it looks good. OK, let’s test it on real mobile devices now. Checking with iOS and Safari – looking good, the same on Android. Maybe even checking it on multiple mobile browsers to be sure about it’s robustness.
And then – let’s run a screen-reader on our mobile devices and test if it is working as well as it was working on our desktop. Wait, how can I change the value of my slider on mobile? Hmm. OK, let’s check how native input type range is working on mobile screen-readers first, shall we? So native input type range listens to gestures from mobile screen-reader and can change it’s value? Why is that not the case with our range made from scratch and with ARIA?
JavaScript has no way to program gestures for mobile screen-readers, so some interactions that are possible with native HTML elements can not be made with ARIA and JavaScript.
My observation from real-world testing
I thought that making keyboard interactions to work would also take care of mobile screen-reader gestures but it is not the case. This means basically that we can not make the custom input type range / slider totally accessible for all devices. It gives us a fake confidence at first and we can use a lot of time but on the end of the day mobile screen-reader user will not be able to use it!
Being aware of ARIA limitations up-front saves a lot of time and efforts on the long run
As described in previous section – some HTML elements may never have their custom, ARIA made, counterparts. Because we may loose some basic accessibility – like we did with input type range made with ARIA and JavaScript alone. If we were aware of it from the start it would save us a lot of time. This may mean that our design would have to compromise on some details.
In my opinion we should check the compatibility before re-creating the native HTML elements that may be hiding much more accessibility features that we recalled. Adding screen-reader and other assistive technology support to the already complex browser compatibility matrix adds additional limitations that we need to take into consideration.
There are even some native HTML elements that are still missing proper support and by creating custom interactive elements or even rich internet applications we should first invest the time to check the patterns and support.
And sometimes design should also know the limitations of styling native HTML elements and accept them from the start. It would save a lot of time and efforts and you know what they say about time. It really is money.
