AI is a fact. Some say it will improve accessibility, and I hope it will, but please consider the facts and new regulation.
Category: Accessibility testing
Latest posts:
Benchmarking of accessibility of different e-government digital services and how well do different countries do is a start, but beware!
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!
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.
W3C Accessibility Guidelines just got a major update. Still a draft, but I love the brainstorming potentials of the newly added guidelines and outcomes. Was the release date an coincidence?
Second Slovenian Accessibility Awareness Day was quite a success, my contribution this time was a manual accessibility audit of crucial WCAG success criteria of larger e-commerces, supported by a team from a11y.si
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…
Do not rely solely on automatic accessibility testing, especially if you do not know that your tool can lie a lot. Use the tools, but educate the people that use them…
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…
Another WebAIM’s Million, this time with different webpages. A tiny improvement, but more complexity at the same time. Can design annotations help preventing some issues that are still rising?
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…
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.
Automatic testing, although limited, is useful for quick and bulk test of webpages. With current progress I would expect it to be more efficient, but such tests could easily be bypassed and we can get bad data.
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.
Sometimes developers have good intentions and want to make their products more accessible, but can fake accessibility and make things even worse.
Don’t think accessibility audit alone will help making things accessible. It can even mean ineffective use of resources as there are several things you need to consider before just auditing.
Making large scale analysis of accessibility based on centralized accessibility statements is simple. But we do need to consider that not everybody filling out accessibility statements have the needed experience and knowledge. And sometimes the intention to be transparent is also absent.
eGovernment Benchmark of 35 countries in Europe (EU and beyond) finally gathered some insights about accessibility of eGovernment websites. After years of accessibility legislation accessibility is still a pilot indicator which unfortunately indicates how late we are in the awareness process.
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.
WCAG 2.2 is here, when do we get it into legislation, like Web Accessibility Directive and European Accessibility Act? Well EN 301 549 seems to be updating in 2025, according to work item schedule it may come in early 2026. Unless ETSI adds WCAG 2.2 sooner it seems that we will have to wait quite a long time.
Municipality avoided paying fines after vendor of e-learning app fixed issues with 4 success criteria out of 6 tested (all A level). I found some interesting facts that seem to reveal procurement and especially awareness problems and I also offer some potential solutions.
9 new success criteria and one less in WCAG 2.2. Removing 4.1.1 from WCAG 2.2 impacting WCAG 2.0 and WCAG 2.1 as well (can’t fail 4.1.1 anymore). Even if three new WCAG 2.2 success criteria are on level AAA I don’t see reasons to not implementing them as they bring much value!
Concentrating on WCAG alone can feel like accessibility is always binary. When thinking about all the success criteria of the WCAG we can quickly conclude that there is not a single medium sized website in the world that conforms totally. A reflection on perfectionism, conformance and reality.
Sometimes best practices are passed as WCAG requirements and that can make accessibility more difficult for some people to implement. We need to understand what WCAG actually requires and what it does not before we try to impact other people.
Sometimes we expect code to work in a specific way. Here is another example how we need to test it to be certain. Status messages are so important that they even got their own WCAG success criteria, but make sure your code really works.
WCAG 2.2 seems to be around the corner, document is currently a Proposed recommendation. But what does that actually mean?