Sometimes they can be a huge burden and sometimes just a small annoyance. A quick reflection on what to think before using…
Category: Practical A11y
Latest posts:
Authentication is often a burden to many different groups of users, but for people depending on assistive technologies it can be a total barrier. What can we do to improve that?
Tables are sometimes critical for understanding, and even if HTML supports quite complex tables we should keep them as simple as possible.
WCAG 4.1.3 is dedicated to status messages and we encourage their use, but we need to be aware of some potential dangers that are often beyond strict technical conformance.
Web Content Accessibility Guidelines touch keyboard accessibility in a couple of success criteria. It’s essential for your native app to support keyboard interactions for it to be accessible. But how?
Grouping is not an exact science, but all designers and developers touching native mobile applications need to be aware of the simplification possibilities it can bring.
Naming is one of the most difficult and enduring challenges in software engineering, and it is obvious that it’s also a giant problem in accessibility. How can you help?
We need to be aware of the limitation of the tools to be able to use them properly and to prevent any bias.
Question of dealing with conflicts between aesthetics and accessibility comes up a lot and sometimes it’s easy to just let one side win and be done with it. I think that we need a cultural shift to have both of them.
Focusing on single channel alone is not enough, how to make sure accessibility is implemented throughout or channels? Leadership needs to lead!
EAA goes beyond technical accessibility. It’s reference to Design for All is a well planned strategical motivator for culture change!
Whenever you test web accessibility you need to consider all the website variants based on all media queries. This can be vital for your time usage estimates!
Sometimes I see complex web components copied to native mobile applications and often they are the cause of accessibility issues.
Any help to make native mobile application accessibility clearer is welcome. We really need to know more to make apps more accessible.
If people treat EAA as yet another compliance thing I think they are missing the greater picture, and probably also greater business.
Bogdan – can you give us an example of a website that conforms to WCAG / is accessible? A popular question with a less popular answer.
Everybody knows that we must not use aria-hidden on interactive elements. But why is that a problem? I decided to check for myself, so that I can explain it better the next time I will be asked.
I like the idea behind aria-errormessage and hope it will soon get enough support to make error messages more accessible and establish itself as best practice. NVDA support is coming soon, but beware potential iOS bug and lack of TalkBack support…
Accessibility audits come in different forms and sometimes it is better to take smaller audits than to wait for the larger ones to be finished – and risk missing out on changes that had to happen in the meanwhile.
Prevention of accessibility issues starts long before we code. It is also true for design systems. Sometimes we need much more time to fix things, even if we use a design system…
Stumbled upon a e-commerce that required hundreds of key-presses to get below the navigation. Reminded me, again, about the importance of skip links…
There are some limited resources on ARIA role application, but I missed more information for mobile screen readers and just quickly checked the situation on Android and iPhone. It seems that support is not there, besides some small quirks. Be even more careful with role = application!
I’ve done quite some accessibility audits and in this blog post I will go into some common ARIA problems and how to cope with them…
If Jakob’s intention was attention, then he got it. Please don’t internalize that accessibility is failed when it didn’t had a chance to even start.
Even with improved CAPTCHA user experience in the last couple of years we still stumble upon CAPTCHA challenges that are difficult to impossible. The situation is even worse for screen reader users and hasn’t changed in more than a decade. How can we help?
After doing an audit of a webpage ,where navigation require horizontal scrolling, I decided to test what does that pattern mean for people with disabilities. Longer story short – be careful, maybe it’s not worth it for critical components like navigation.
I wrote a lot about automatic accessibility testing, but from developer and accessibility auditor perspective. In this post I summarize some reflections on accessibility tools for content creators – the authors.
I feel that design is too focused on the visual parts and therefore the burden on non-visual design falls on developers. What can we do to improve this? To fill the gaps?
I would like that accessibility is the default, just there, without effort. Just fixed for all of us. But it’s not yet possible. Probably never will be. And when I try to be open minded and try to use a feature of accessibility overlay and it just fails, not one but two features, under two minutes, on an important page for people with disabilities, then I had to write about it. And even make a video of it.
A little knowledge is a dangerous thing proverb goes also for accessibility. When we are motivated to implement newly acquired knowledge after a training we can quickly start overusing techniques and can even make our product less accessible.