Automatic testing of software is brilliant. Saves a lot of time and effort, prevents problems soon and makes our products better. But when trying to automatically test accessibility we need to know about the challenges and problems before. Some tools may even produce wrong results and some tools may report everything is perfect when they can only test up to a third of criteria.
Tag: DOM
Latest posts:
Every (front-end) developer should add screen-reader to their tools. Screen-reader experience can really help us make products more accessible and also be better at our coding. Combinations of screen-readers and browsers can get over complicated, so it is important to think if code we write is supported for majority.
Some thoughts about accessibility of three-dimensional web user interfaces and what are our options to cover user needs. HTML canvas can be enriched with either sibling DOM or fall-back markup and if we think of single-dimensional interfaces then we can also make three-dimensional interfaces accessible.
I wanted to expose sweet points from the Making Facebook.com accessible to as many people as possible article that was published on 30th of July 2020 as it is an excellent example of continuous and from-start accessibility in my opinion and we should all implement at least some parts of it in our work-flows.
I have done some quick practical testing and research about cookie consents accessibility, usability and also some testing with search engines – on some websites in Europe, to see what are consequences of cookie consents for users, owners and search engines.
This API is just an interface that assistive technologies and user agents use to communicate. It is important to know that there are differences between vendor solutions so testing is a bit more complex but crucial.
They say that sometimes you can not see the forest for the trees. But in web development you really should think about the forest of multiple trees to understand how it connects.