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.
Tag: WCAG
Latest posts:
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.
Time flies and after four years of directive we can reflect a bit more on the positive effects beyond public sector.
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.
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.
EAA goes beyond technical accessibility. It’s reference to Design for All is a well planned strategical motivator for culture change!
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!
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!
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.
Short reflection on positive and negative situations related to accessibility standards. Unification, or to say standardization of accessibility standards, should be our common goal.
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.
Quarter of a century later and we still don’t have enough awareness, support, knowledge, buy-in for accessibility. It is improving, but slowly, we need even more advocates.
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?
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?
Personal reflection about my encounter with web and accessibility, how I was ignorant of it as well and how I think we can’t be ignorant any more.
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 try to open my mind and reflect on some possibilities that would maybe, perhaps, make accessibility overlays viable solutions. Then I quickly find the downsides and don’t change my mind about them…
Sometimes developers have good intentions and want to make their products more accessible, but can fake accessibility and make things even worse.
Sometimes when I audit webpages and mobile apps I really wish that parts of WCAG AAA would just become AA, to improve the user experience and to make things better for more users.
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.
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.
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.