Sometimes I see complex web components copied to native mobile applications and often they are the cause of accessibility issues.
Tag: ARIA
Latest posts:
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…
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…
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?
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!
Just a quick brainstorm when checking a design wireframe for potential accessibility issues, finding low level problems that may be solved way earlier than we may think. Maybe even before designer became a designer and before developer became a developer?
A post from fellow accessibility specialist made me think about why people think accessibility is difficult. I think that awareness, knowledge, ethics, involvement and responsibility can help a lot.
When developers discover ARIA and try to misuse or overuse it we get more problems than we may have before. It’s not just that, even if they do everything correctly we risk to have an inaccessible product due to missing support of theoretically great ARIA.
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.
After giving a talk about accessibility and discussing the lack of awareness I decided to reflect on some thoughts in this post.
Are we ready to use native HTML dialogs in production? As often – it depends. Please don’t take it against me but it really depends. Some users are still forced to use older browsers, polyfills seem to be problematic, so most often we are still stucked with ARIA based dialogs. For now.
Accessibility tree in browser and screen-reader’s speech logs are extremely valuable tools when we want to check how HTML, CSS and ARIA translate to assistive technologies like screen-readers, no doubt about that. But please make sure to go through to the end – do listen to your screen-readers and in different combinations with browsers. As sometimes that’s the only way to find out about real problems.
In this blog post I go into details behind automatic accessibility testing and how I don’t really trust any accessibility scores such tools provide.
It all drills down to inability of automatic tools to pass WCAG success criteria and limited ability of them to fail some. Manual testing is the only real way to really know about state of accessibility.
Before you order your accessibility audit you should read this article of mine. I try to be objective and constructive and present the good and the bad, the strengths and the weaknesses of accessibility audits.
The journey from content creator to end user is quite long. At least in terms of different software that needs to deliver. And as we all know – software has bugs. And sometimes even so called features that can actually be called bugs as well. So please test and if we find a problem – report it, so that we improve the accessibility one step at a time.
I had to fail an Android app in a recent WCAG audit because it’s expand/collapse components didn’t have the semantics. On the review I got asked about possible solutions and here you go – hope it will help somebody make accordions on Android more accessible.
We all reach out to third party solutions and we like it when they claim they are accessible. But please don’t just believe them – check that they really are conforming. And when they update – check again.
Sometimes it’s simple to make a feature with JavaScript but not so simple to make it consistent for all those screen-reader and browser combinations. In this post I describe how I tried to update some live regions and the order in the DOM was not respected. Solution was simple, but it’s easy to forget about it when it works visually.
Some improvements can be detected and I also added some thoughts of mine about the parts that are not very obvious. Interestingly – e-commerce is almost worst – and that really is a surprise when we think about how much do they invest into ads and SEO, just to get some new users.
Some accessibility issues originate in code. And when design is being recreated with code it may seem to work but when thinking about accessibility we may notice that it only works for some users and not for others. I’ve decided to describe some common accessibility fails that are on developers.
I was asked if I can issue “WCAG certificate” for a website, so I decided to investigate what would that actually mean as we all know that sites and mobile apps are constantly evolving and changing and even if they conform to WCAG they may not the following day. What would then mean to issue a WCAG certified certificate and still be ethical and the right thing to do?
Why do status messages matter so much they deserve it’s own success criteria in the WCAG? Well, it is just a minimum – all users deserve to be informed when something important happens, also users of screen-readers and other assistive technologies.
External agency made an accessibility audit. It provided a lot of possible solutions. In this post I try to make it easier to act on this audit. Breaking results into responsibilities, then prioritizing the issues and finally estimating and fixing them can be one way of doing so.
To claim that our product is accessible needs more than just WCAG audit that did not discover any fails. Real users, people with disabilities are the only one that can really reflect on the accessibility of our products. That’s why we should include them in all reasonable parts of our production processes. Otherwise we may think we deliver accessibility but the truth can be opposite.
Inspired by others – I reflected on the origins of accessibility problems in design. It’s not so strange when we think that design is the implementation plan and if plan is not accessible then the final product will most certainly also not be accessible. Code, low-code or no-code alike.
Sometimes people claim that accessibility is the responsibility of development and code. I disagree. It is a team effort and it can only succeed when whole team knows what to do. Content is king and if we start and end with content it can make the teams accessibility efforts much more effective.