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?
Category: Practical A11y
Latest posts:
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.
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!
Brief reflection on 3 years of WAD in EU and short version of attending WAD anniversary event which was really worth attending.
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.