We finally made an official Global Accessibility Awareness Day in Slovenia, and I am proud that I was a part of it and even had two presentations. It was amazing to meet a lot of people from different organizations connected to accessibility and to greet people that I cooperate with in-person for the first time.
Posts
Are accessibility overlays common on Norwegian municipality websites? Short answer is no, luckily. But when they are they really messed up the site. Not only accessibility-wise but also on mobile devices / smaller screens / when zooming in.
I am not the only one concerned about accessibility and it seems that I also had similar timing, methodology and results. I didn’t go all in with the crawling of absolutely everything and I didn’t test the documents as they did. So that’s why I made a short summary to enrich my own analysis.
This is the fourth part in a series and in this post I expand the automatic analysis report to cover approximately 50 webpages under each of 356 Norwegian municipalities – 17837 URLs to be precise.
The general outcome is quite interesting and I was surprised to see some very positive trends as well.
Accessibility statements can claim all sorts of things but we should test as much as we can to establish the reality. The simplest and quickest way to do that is to use automatic tests. In this post I reflect on the results of automatic tests of homepages for all Norwegian municipalities. You will be surprised as I was.
Accessibility statements required by Web Accessibility Directive are quite efficient indicators of websites accessibility, when sites are audited by professionals with some experiences. We don’t have better data than this at the moment, so let’s process this a bit and then dive into numbers and findings.
What is the state of accessibility of municipal websites in Norway? Now we can get some data based on their official accessibility statements. While doing so we can also draw some conclusions, but this post is only the first part of a series of posts on the subject and talks mainly about motivation, methodology and preparation.
I love WebAIMs Million, but I need to point some things out. Some people may come to wrong conclusions after reading parts of the report and I hope I can improve that. I also think I know the reason and the solution about the still very poor state of accessibility.
I stumbled upon a lot of websites that had untrue accessibility statements. It’s quite easy to know when they are not being honest actually. Some goes even so far to claim they are compliant and conform to WCAG 2.1 on AAA level while their autoplaying hero video with no controls is screaming “lies” to me.
I wanted to check for myself it ChatGPT can help delivering more accessible code. And after multiple trials I gave up. The reason for it’s confident but wrong example code is clear to me and when you read this post it will also be clear to you.
Do we have more accessibility specialist in 2023 compared to 2022? I got the numbers from IAAP and it’s looking better. And some countries are really doing good, check to learn more about which countries got most new certified professionals.
Once again a discussion I had on problems with headings after an accessibility audit. Can we get it right and can we have a sustainable solution? I believe so!
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.
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.
In 2023 we got some updates to Norwegian accessibility legislation and I try to summarize the newest situation in this short post.
Private sector should embrace accessibility statements and feedback mechanisms. Starting with measuring accessibility in processes and products and then documenting it in public while offering feedback is the best way to go.
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.
Please forget about automatic document outline and plan accordingly. Make it work for people and not for search engines. It’s once again a team effort – design, develop and content.
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.
Being busy with accessibility audits because everybody want’s to make their accessibility statements made me think about usefulness of them. When is an usability statement useful? Hint – it’s not about how good your Lighthouse scores are. It’s about how you can help real people with real problems.
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.
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.