After giving a talk about accessibility and discussing the lack of awareness I decided to reflect on some thoughts in this post.
Are we ready to use native HTML dialogs in production? As often – it depends. Please don’t take it against me but it really depends. Some users are still forced to use older browsers, polyfills seem to be problematic, so most often we are still stucked with ARIA based dialogs. For now.
What would I have in an automatic accessibility testing tool if I could have anything that is possible with today’s technology?
Well, I would start at the beginning – clear scope and known priorities is a start and sometimes we can’t really cover all that when we have to choose where we need to focus. Next, I would like to teach the tool, so that it will be more and more independent. And because I like to stand for my decisions – I would like to use the blockchain to prove my efforts and fixes. Words can be empty, deeds talk.
Some improvements can be detected and I also added some thoughts of mine about the parts that are not very obvious. Interestingly – e-commerce is almost worst – and that really is a surprise when we think about how much do they invest into ads and SEO, just to get some new users.
How do you test for something that can be only possible in certain conditions? Well, best way to do this kind of testing is to ask developers and others that were involved in the feature specifications.
Some accessibility issues originate in code. And when design is being recreated with code it may seem to work but when thinking about accessibility we may notice that it only works for some users and not for others. I’ve decided to describe some common accessibility fails that are on developers.
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.
Web is full of sticky or fixed elements and they may add to usability for some users. But if we think about variety of different users we may quickly note the possible problems for them. Covering too much screen, covering important other elements, or even blocking users totally can be prevented with proper planning and testing. This article tries to map the problems as a first step to proper awareness.
Time flies and this blog has now 100 posts. Counting posts does not count for much but I try to consistently write about accessibility to think out loud. I also tried to summarize some quite special thoughts about complexity and how accessibility must be a team effort to be successful. On the end I also added some stats…
I wanted to describe the importance of ARIA for mobile devices. Especially when we have to be careful with ARIA and maybe just accept the fact that native HTML element can be much better choice. Sometimes graphical design should embrace the limitations that styling native HTML elements bring.
Where to start as a developer or designer wanting to test with screen-reader? With basics, right – and maybe with mobile first. But do not underestimate real users – they might surprise you.
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.
Automatic tests can help a bit. WCAG evaluation methodology provides a good start for test focus. And if we add page popularity scoring and simple page complexity scoring, then we can really focus on the potentially difficult pages in our manual testing efforts.
Animation can enrich the content, sometimes content is animation, and sometimes animation is preventing users to understand your content or even giving users a really hard time or in some cases even make them sick. So please be responsible with animation, and most importantly – let user control it.