Demographics tells us that we need help. Automating the physical world requires robots. We need them to be accessible!
Tag: EN 301 549
Latest posts:
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.
Is it just me or is it weird to require and encourage the use of standard and at the same time hide them behind paywalls and even make them inaccessible?
This is a summary for my Universal Design 2024 (UD2024) conference contribution, where I was using parts of EN 301 549 and WCAG to check how (in)accessible are iOS and Android mobile applications from 4 largest Norwegian banks.
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?
Native mobile applications are often more focused and with that – less noisy for users (and I meant that visually and non-visually). But platform choices can lead to inevitable inaccessibility as some abstractions lack support.
I lead a project to manually test 20 Slovenian e-commerce websites and wrote an article about it, called (In)Accessibility of Slovenian E-commerce the Year Before the European Accessibility Act.
We need to be aware of the limitation of the tools to be able to use them properly and to prevent any bias.
Don’t get too concerned about the differences between WCAG on levels A and AA and instead use the energy to go beyond and implement AAA.
I am a bit biased towards technical parts of accessibility, but when I studied EAA even more, I finally understand why it does not try to be technical.
Benchmarking of accessibility of different e-government digital services and how well do different countries do is a start, but beware!
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.
Short reflection on positive and negative situations related to accessibility standards. Unification, or to say standardization of accessibility standards, should be our common goal.
Sometimes developers have good intentions and want to make their products more accessible, but can fake accessibility and make things even worse.
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.
Autocomplete and correct keyboard layout when filling out forms are simple and powerful helpers to make less errors when filling out forms. They benefit everybody, but they are even more appreciated by people with different disabilities. Web support is there for years, but what about native mobile applications?
I don’t like the fact that EN 301 549 is provided in PDF format. It’s way simpler to process HTML. And when I did some parsing I figured out I could also check how exactly does EN 301 549 goes beyond WCAG for web and mobile applications. Quite a lot is the short answer.
I received a brief question about Web Accessibility in Norway and if it is different from the EU and decided to write a short post as an answer.
After auditing some native mobile apps for accessibility I tried to understand the capabilities and possibilities of native mobile platforms for Android and iOS applications. In this post I try to reflect on the fact that making native mobile apps accessible can be much harder than when we try to make web accessible.
Writing a blog post on the 25th of December allows me to write about wishes. And one of them is to have better tools for accessibility auditing.
This post tries to describe what I would like to get from the tool. Realistically, noting too advanced.
It was not clear to me if WCAG 4.1.3 can be applied to native mobile applications. At least on both iOS and Android. So I did some research and came with the conclusion that we can and should or even must use status messages also on native mobile apps.
Minimum viable product that is not accessible is not really minimum. And then also the WCAG on level AA is the minimum, a baseline. When we reflect over those two facts – we must agree that MVP must at minimum conform to WCAG 2.1 on level AA. If this MVP will run in EU’s public sector even WCAG 2.1 on level AA alone is not the minimum.
23th of June 2021 is the final step of Web Accessibility Directives mission to improve accessibility of web and native mobile. WCAG 2.1 applies for mobile as well, but there are some exceptions. At the same time I touch the importance of accessibility in our Covid / Corona pandemics situation.
Extremely valuable documentation that reveals some interesting points about future of Web Accessibility Directive monitoring methods, tools and also some less clarified reporting matters. The accessibility statement automatic analysis will most certainly also have a central role and it is worth following on the Accessibility Conformance Testing rules that are the engine of all automatic tools out there.
Beside content accessibility guidelines we must also be aware of authoring tool accessibility guidelines that your editor tools, for example content management system, should adhere to