Looking back at 2022 I can say it was not bad, not bad at all. Incredible experiences, knowledge getting and sharing, contributing to open source, starting my own company, and being invited as a professional head of an newly started institute.
Year: 2022
Latest posts:
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.
I’ve learned that WCAG can’t be changed a lot and that only additions are allowed. Now I’ve read that WCAG 2.2 will have the 4.1.1 success criterion (parsing) removed. My first reaction was – why and how will we work with problems in HTML then? On the other hand we should probably be happy we can focus on other problems that are more related directly to accessibility.
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.
On 25th of November 2022 I finally got my idea out as a sole proprietorship – under the name of IDEA-lab Cerovac (IDEA as Inclusion, Diversity, Equity and Accessibility and lab as laboratory).
This post tries to explain a bit about the ideas behind IDEA-lab.
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.
What would I have in an automatic accessibility testing tool if I could have anything that is possible with today’s technology?
Well, I would start at the beginning – clear scope and known priorities is a start and sometimes we can’t really cover all that when we have to choose where we need to focus. Next, I would like to teach the tool, so that it will be more and more independent. And because I like to stand for my decisions – I would like to use the blockchain to prove my efforts and fixes. Words can be empty, deeds talk.
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.
Attended web performance conference (performance.now()) and found some thoughts about similarities with accessibility. Also made a simple proof of concept for a time to interactive metrics for screen-readers and other assistive technologies.
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.
Trying to set a baseline for making more accessible custom interactive components. Yes, you should refer to whole WCAG and I refer to it as well, but this can be used as a good baseline as well. Hope it can help somebody.
Some reflections after two years. Progress is slow, but steady. Personally I would invest into automatic testing solutions to monitor some basics, but that’s probably not possible before stakeholders, politicians and organizations really understand the impacts.
Website owners are responsible for use of third party widgets, plugins and more. Before using them they should check if they conform to WCAG, otherwise their site will not conform either. Checking for accessibility statement of the third party may reveal huge problems with their product’s future.
Another reflection on the business impacts of making things accessible. Investing in accessibility now will for sure make commercial advantage for us as people or companies. It’s not only the right thing to do, it also makes sense commercially.
Finding errors and failures is quite simple. Finding their solutions not so much. Audits should in my opinion provide with specific solutions that are not vague and are totally actionable. Otherwise we need to call in other experts to translate them.
Time flies, and I am WAS for two years now. Short reflection about the past and the future that WAS has for me.
As I enjoy my vacation I decided to write a bit more personal post, still related to accessibility, but no technical details.
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.
I am honored to be a protégé of such an amazing accessibility professional as Léonie Watson is. Besides being a nice person she really invested into her time in our sessions and I made quite a progress based on her feedback. This post is trying to describe how it all went and concludes with my recommendation to anybody – get yourself a mentor before you can become a mentor yourself.
Mobile native applications are often with no headings. Sometimes even have visual headings but are missing on the semantics. Screen-reader users can and also like to navigate via headings, so we should be responsible and use them. They are supported on both iOS and Android.
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.
We are most probably failing a WCAG success criteria 1.4.10 Reflow because of CSS’s inability to fix word breaks for us. What can we do to allow grammatically correct word breaking when our browsers can’t help us yet?
Just a brief reflection on the business side of the accessibility equation that can easily be set on side.
European Accessibility Act will for sure have huge positive effects on the e-commerce, and I hope it will help also other sectors and small-businesses.
What are the most critical requirements for testing native mobile accessibility? What do we have to have for testing? Should we only test with phones? What about different operating system versions? This post will give you some basic hints.
Navigation between pages is so natural for us that we don’t even think about it. And obviously it can also be forgotten when using newer technologies like Single Page Applications. Although a decade old, some are still not really accessible as navigation is not announced to screen-reader users. Let’s check what works and maybe have a conclusion.
Re-watching Uncle Bob’s Clean code videos made me think about ethics in digital production that is unfortunately not mainstream. Accessibility should for sure be a part of it and I reflected on both here in this post. A bit philosophical, but nevertheless important.