First thing first – I will not name any party in either positive or negative way. It’s actually quite easy for me to be totally neutral, more so as absolutely all websites have critical accessibility issues. So – unfortunately – I can not say this and this party has really done a good job with online inclusion. But I can point out some accessibility issues and hope somebody can learn from this. And, hopefully, improve.
Briefly on methodology
Some really tried, that is obvious, especially when we consider automatic accessibility tests that do not find any issues or sometimes find just a couple of issues. We can expect this when we consider similar studies done on European level, so nothing new here. A similar study has been done on the European level (opens in new window) and findings are very similar to mine here. Norwegian authorities have also done a similar analysis in 2017 (in Norwegian, opens in new window) and to no surprise – all websites had issues then as well.
Due to the limitation of automatic accessibility testing – I really need to point this out once again – automatic tests can only find obvious issues and can never confirm that pages are indeed accessible. For simplicity we can establish that automatic tests potentially find about 30% of WCAG issues, but we really need to be aware that these issues are mostly code-based tests without context.
When we do some basic manual accessibility testing, we quickly find issues even on pages that have no automatically detectable issues. Often issues that could easily be prevented, like for example missing support for keyboard support, invalid or missing alternative texts, missing or invalid skip to content links, pages that are not responsive to different screen sizes and so on.
I’ve tested 29 home pages of political parties in Norway – parties that are currently in parliament and also those that try to get in now. Time frame was about two weeks before election. I will update the post with automatic testing results soon, but for now I will mainly discuss the findings of “lightning fast manual accessibility testing” that I’ve done to find more about the reality and not only rely on limited automatic tests. Testing is based on parts of WCAG 2.2 and EN 301 549 v. 3.2.1.
Findings
As mentioned – not pointing fingers, keeping things on a high level, mostly to point out what needs to be improved if politicians really want to demonstrate their wishes for inclusion of all of us, including people with disabilities.
Critical accessibility issues
I did this voluntarily, so I had to limit my time and effort. Nevertheless my testing results unfortunately assure me that people will have difficulties when using these websites. Especially people with disabilities that rely on assistive technologies, not limited to visually and physically impaired, although they will most probably notice issues first.
- Only 13 out of 29 websites has the correct implementation of skip to content links. All of them should have it, but 12 don’t have it at all and 2 have it in English (I suspect due to the template and not planned for) and 2 even have it in English, but it does not even work. This can actually mean website causes physical pain for some people. Or at least steal their time.
- 25 out of 29 websites had issues with alternative text. Some was a part of the template (like for example logotype wrapped in an link) and some were content related – like an article teaser with cryptic filename as alt text. Basic accessibility issues, but critical for people that rely on the alternative texts. Some pages even have paragraphs of text in an image while others include empty links and buttons because of graphical elements that do not have proper alt texts.
- 24 out of 29 websites had color contrast issues. Mostly text versus background, but also interactive elements and focus indications. Readability suffers when websites have poor contrasts, strange that people still don’t understand the importance of this.
- 18 out of 29 websites had critical semantic issues. Clickable div or span elements (often for main navigation), form issues (validation, required fields, labels), missing status messages and so on. A clear indication of low to none effort for users that rely on their assistive technologies like screen readers.
Some specific findings we need to learn from
In no particular order, just wanted to add them here for reference, and hopefully for people to avoid them in the future:
aria-hiddenattribute on interactive elements – basically making a mess for people using a screen reader and other assistive tech.- Chat interface (third party) defined as English in code, but actually containing Norwegian text – this is often a giant issue for screen reader users.
- A carousel causing a strange keyboard trap when going backwards with shift tab.
- I’ve seen it all – a
tabindexvalue of 200. Making the keyboard jump all around the place with othertabindexdefinitions. - Alternative text without no value – “image” or “cropped” and even
${title}. First two were content related and the last one was, as you can guess, a part of the template. langattribute set to English – on whole body but all the text in Norwegian – often a giant issue for screen reader users.- Dynamic placeholder text – where a huge search input field swaps it’s text every second or so. I needed to check the code to actually find out that it was indeed an input field and no, no way to stop the animations.
aria-expandedattribute always true – let’s make screen reader users guess when additional content is there or not, shall we?altattribute on adiv– somebody tried, but unfortunately it does not work like this, even ifdivcontains an image background.
One party even have an accessibility statement
Yes, yes, I know, they are not required (yet (!?)). Still – I suggest having an sincere and useful accessibility statement for every webpage and app.
As a political party, I think it makes a point. But only if it is helpful. And our accessibility maturity is on a level where we know what we still need to improve and are working on it. Do what you preach comes to mind (sometimes hard for any political party). Unfortunately there were basic accessibility issues on the page, and the statement was very general, in a way “we strive to WCAG”. But at least they had a contact form there.
Conclusions and speculations
I think I could see a direct correlation between a (bit, at least) better state of accessibility for those that had some kind of styleguide.
And those that used some no-code or low-code based solutions (or at least a decent template) got some template based things a bit better than those that were more custom (even if sometimes visually hidden things were not translated).
Some seem to care about automatic accessibility testing (or at least Google Lighthouse scores, we can speculate), but the devil is (always) in the details. Therefore manual checks, even if done in a hurry, will obviously reveal the reality better. Even a basic keyboard test will tell a lot of tales, way before getting into code.
Many accessibility veterans say that accessibility is political and there are thousands of different ways that confirm it really is. Some parties do have accessibility in their programs, but not all of them want a more accessible society (scary). That would be a study for other time, but it’s obvious to me that we still need more work when it comes to accessibility, even if we say we care. Practically all issues I stumbled upon are quite easy to fix, yet better prevent, it’s all about awareness and it often does not cost any more when we have the knowledge to prevent them.
So – I can use this opportunity (you know, if some politician will read this) – to publicly wish that accessibility is a priority and not just some specialization. Shifting accessibility to “the left” does not mean the political left – it means to shift it earlier into processes! I would even hope earlier in our lives. If we would learn the basics soon enough we would really have the possibility to make our societies more inclusive!
