Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

Automatic Summary

Understanding Web Accessibility: A Developer's Perspective

Hello! I'm Evan Panola or Evis Panola, a senior software developer and web accessibility specialist at Futures Finland. In this blog, I will provide insights about web accessibility and how developers can make their websites inclusive for all users, regardless of their abilities.

The Diversity of Web Users

The diversity of web users is vast - not everyone can see, not everyone uses a mouse, not everyone has good fine motor skills, and many aren't that proficient with technology. We, developers, being power users, are often guilty of creating websites with ourselves in mind. However, our responsibility is to create websites that everyone can access effortlessly.

Who Is This Blog For?

This blog is for both experienced developers on their accessibility journey and those completely new to the concept of web accessibility. This blog provides concrete checks and suggestions to enhance your site’s accessibility. In addition, I will also share a link to a page with more checks and explanations.

The Need For Manual Checks

I am a strong advocate for manual checks in web accessibility. Automated accessibility testing tools, though helpful, can only provide binary results based on the code provided. They cannot grasp the complexity or context of an item, such as an image’s alternate text,
as humans can. Studies reveal that automated testing can only detect 15-40% of accessibility failures, thus the necessity for manual testing.

Common Issues and Solutions

There are several recurring accessibility issues I have encountered in my career. Here, I’d share two of such issues and their solutions:

  1. Disappearing Focus: This occurs when certain items disappear when attempting to navigate the site using only a keyboard. It leaves users lost, without any interactive features. This can be rectified by ensuring that all interactive items are included in the tab order and are not removed from the Document Object Model (DOM) when not in use.
  2. Focus Indicator Removal: Some developers remove the focus indicator because they consider it to be visually unattractive. But removing it makes sites inaccessible to many users. The focus indicator is crucial for navigating the screen, and I strongly suggest keeping it or replace it with a more visible one.

Page Language

An important aspect of accessible web design is setting the site’s main language using the lang attribute in the html tag. However, if the page contains other languages separate from the main language, setting the lang attribute in textual elements is also recommended. This assists screen readers in interpreting and reading the text in the correct language. A detailed example can be found in my post on developers' checklist.

In conclusion, web accessibility is an integral part of web development that ensures the inclusivity of all users, regardless of their abilities. As developers, we must carry on this task diligently.

Thank you for reading, and you can connect with me on Twitter at @EevISPANulA or visit my website at Eevis.codes for more insights.


Video Transcription

Uh My name is Evan. No Panola or Evis Panola. I'm gonna refer with that name to myself too. So don't get confused and uh I'm gonna say a couple of words about myself during the presentation. So I'm not gonna introduce myself more here.So let's start we as developers, we sites for users like ourselves and that often means a sighted uh mouse user who has uh good, fine motor skill and um could be sometimes described as a power user, but not all users are like that. Not everybody can see, not everybody uses a mouse, not everybody has fine, good, fine motor skills. And well, there are lots of people who aren't that comfortable around computers. So we need to think about those users too. And um I want to say that it, it's like I I'm not assuming that uh I'm assuming that nobody is doing these things out of evil thoughts or, or malice or anything. No, that's just like it's a human thing and, and that we are seeing the world from our point of view. But as developers, we need to broaden that view. And um also think about the users who aren't just like us and that's why I'm talking today about some checks that a developer can do while developing to ensure that um also like users that are not like them are taking like, well, they are also um yeah, sorry.

Um losing my words here. So like I think you understand what I'm trying to say here. So yeah, um this talk is intended for those who are in the beginning of their accessibility journey. You might be, you might already know that something needs to be done. But there are so many things that you need to know or learn or do or or something you might feel, feel a bit overwhelmed with everything. And my intention is to uh provide some checks, some like easy to do concrete checks you can do to insert accessibility. And it's also possible that you, you have no idea what I'm talking about, but that's totally OK and I'm happy that you are here and I hope that you are learning. So, yeah, uh My name is Evan Panola or Eves Panola and I'm a software developer or a senior software developer and access specialist at Futures Finland. And um I mostly do front end focus stuff and I'm also a certified professional in web accessibility. And um today we are going to talk a bit about automated testing and then uh I'm gonna present some checks that um well, help with developing and um there's gonna be only few of them because of the time constraints here. But uh I'll also share a link to um a little more checks with explanations and, and these kind of things. So, yeah. All right.

Uh First couple of words about automated accessibility testing, what I mean with automated accessibility testing is basically all those tools that take some um some sort of code uh go through it and look for, for like things that can be actually um found programmatically. So for example, if you have an image stack or image element on your html code and uh it doesn't have the old attributes. So alternative text attribute at all uh that's something that uh these tests or, or like tools can find. Or for example, if you have a um like they can check that html uh element has this LAN attribute and they, they can see if it's missing or if it's not missing, but they can't really um like they can check things that are are either yes or no. But then when we go into more complex things like for example, what the old text should be for for some images, then like these automated testing tools can't really say if this is good or bad. For example, or if it's a failure or an issue or not. Just um for example, for images, the the um alternative text there should be uh it totally depends on the context and on the on the like image and and like what's there and what that image is trying to um communicate. So it's hard to know what there actually should be and like programmatically, you know, so that's why um manual testing is needed.

And um actually, if we look at studies on this topic, they say that about 15 to 40 or, or 50 depends, it really depends on the study of the like uh only from 15 to 40 or 50% of the accessibility failures uh through automatic testing. So that's like 50% at best. And that other half needs like um it needs a human checking or testing to like find all these um like issues there. So yeah, that's why we need to check manually too and let's go into those checks. Um Yeah, so that I'm going to present today is to test the a key board. So this means that uh when you are developing just like you can unplug your mouse or just like not touch it and try to navigate through the site with only a keyboard. So basically tapping, for example, tapping, like using the tab key to navigate through your site and um test if you can use every control there is that you could use with a mouse. So um you might find that there are like places you can't get to with a keyboard on with only a keyboard or things that you can't do with only a keyboard. And these are things that need fixing then. But I'm gonna uh show you some of the I could say most common, common things I find when I'm testing, for example, sites with only a keyboard because I'm a mouse user or like I could say I can use a mouse, I'm using keyboard a lot even though I can use a mouse.

So, so I come across these things um sometimes, well, a lot. So yeah, and also I, I do testing. So I come across these things also like in those settings. But yeah, so we are going um I'm going to represent two things about disappearing, focus and then uh unusable controls. But you'll see what I mean when I'm demonstrating this. So I'm starting, I, I'll start navigating. So um I'm sure if you can hear my uh loud uh keyboard when I'm tapping, but I try to also say it when I'm, I'm doing the tab. So I'm navigating there. All right. So right now the focus is on a checkbox next to a show list label and it's just there for now to just pause here and that I can say that, OK, next, I'm, I'm going to tap to the next item and I would imagine that it's the button that says I am also visible. So let's try that I'm gonna tap. OK. No, we like we are completely like no idea where we are on the um screen right now. Let's try again. Tab. No, again, tab, no, and then tab oh Here we are. So now we are on the button that says I am also visible.

So uh by the way, what I forgot to say is that um I have this focus indicator which is uh like pink or red, depending how the screen is, is like interpreting colors but like pink or red, um rectangle uh around the focus all element. So there is the focus currently. So yeah, but like for a while, we will, we were completely lost and there was no idea or no way to know where we were on that like uh page currently. And the reason for that is I'm gonna navigate backwards and I'm gonna toggle the show list. The reason is that there is a um list of links which was hidden. Uh and and how I was, I I had hit them was to um I was just positioned, I'm sorry, they were just positioned outside of the view, meaning that um I was, I had used something like CS S um position absolute and then like left minus something to just get them out of the view, but I didn't remove them from the dom, I didn't remove them from um focus order or tap order.

So that's why they were still there. So when I was just navigating like I'm doing now, the focus went there to these items which weren't visible. So that's why it was really confusing for a while. So yeah, um that's one thing and, and this happens often with, for example, menus, navigation menus because, well, uh some like those lists of links are visible when, when somebody is, for example, hovering over a certain icon or something. But then like they, when, when not covering, they've been just moved out of the view. And if they haven't been hidden, inclusively meaning that they, they are either like removed, completely removed from the dome or just like hidden from screen readers and, and removed from that order, then like it's good for uh most users but not for those who are using some other ways of navigating.

So for example, keyboards, keyboard emulating devices, screen readers. Well, they, they use also keyboards but like it's a bit different with them. So that's one thing and I'm gonna continue navigating here. And then now I'm again on that, I am also visible button. And um next place I would imagine the focus would land is this, I have no focus indicator link and then after that to this, but I have link. So let's test tab. OK. Focus is not visible and then again, tab, now it's again there in the but I have so why this happened is because um I had removed the focus indicator from the link with CS S property outline set to none which is fairly common pattern. And um I'm sorry for that because like usually the reason for that is that people say that, OK, like um it's just ugly, let's remove it. There's no use for it. But the truth is there is a use for that uh focus indicator which like is usually like the native way of setting it is with this outline po So I um hope that if you are ever removing the out like the outline with outline, none, you do it because you are making the focus indicator even more visible with some other ways.

So there is that. But if, if it's just for the reasons that it's ugly, then um please don't because for some, it is essential for navigating and and the site if, if the focus indicator has been removed, then um these sites are unusable. So yeah, and then there is this unusable contrasting. So um I'm gonna um use my mouse for a while. So there is this button that says click me, I'm gonna click it. OK? All right. It seems that um this doesn't share the uh alert but it like what I'm seeing right now is that um there is an alert saying that click happened and um I would imagine that I could do the same with um key with keyboard too. So again, I'm in this but I have link and I would imagine that the click me button is the next one where the focus would land. Let's test. Nope, it just went past it and it's on the next link reason for that is that, that so-called button is not a button at all. It's a div made up. Well, it's a div which looks like a button and has a on click handler attached to it and nothing else. And that's really problematic because um it means that there is no like roll button. So that screen readers would know that there is a button.

Uh it's not in a tab order so that you like um keyboard users can for example, focus to it. And then there is no like handlers for uh keyboard events. So it's not even usable if they could focus to it, they can't use it. So I really hope that if you remember one thing from my talk, it would be this use always native semantic elements. So for example, if you are creating a button, use button and not a div which has something like on click handler or something else. So um I hope you, you'll remember that. All right to the next thing. Uh I'm gonna say a couple of words about the page language. So I, I was referring to that in the intro. But um what you should do like the, the check for this item is to check that uh opening the by opening the DEV tools, developer tools. There is this uh sources or like, I'm not sure what it's called called in uh other browsers that I think in Chrome, it's called sources, but you can find the html code from or, or the like document from there and you can check that in that document there is this html tag or element and check that the L attribute it has is the same as the real um language of the page.

So for example, if the, if the page is, it should be en or if it's in Finnish, then it should be F I or if it's in Russian, it should be ru and so forth and uh with the language, I mean, the main language. So what's the like most used there? And um I'm realizing I'm a bit running out of time, but I actually want to show this video. So this will be the last check that I'm I'm showing, I'm sorry, it was only two and not three this time. But yeah, so um OK, you check the main language or you have the main language there. But what if like you want to have or you have some other language inside the um the whole page, like for example, you have English text and there is some French inside of it. Should you mark that with somehow or something? Well, yes, you can add that line attribute to, to for example, paragraphs or spans or DS which, which are, which are like textual elements. So where you can add text, you can add this line attribute. And um now you might be wondering why he, I should have said this first, but I just, I was looking at the clock and kind of got confused at that point.

So the thing that I should have said first is that um like screen readers use that information for reading the um uh the text in a correct language. So if it's set to English, they, they read the um pages text in English and if it's set to finish, they try to read it in f but if text is actually in English, then it's pretty problematic. And here I have a demonstration of that and um I'm not sure how it's gonna sound to you because um well, for me Finnish native, I can understand that, but I'm not sure how it sounds to you. And OK, yeah, that, I'm really sorry. I, I have rehearsed this and I should have been able to deliver this on time. So I can't really show that video to you to. Um So because like this session is gonna end in one minute so I can't show it. But um I'm gonna skip to the last one here. I'm already gonna say thank you. If you want to see the video, you can go to my blog post about these uh steps. So it's in tinyurl.com/developers checklist. There is one point about page language and um it's there, you can see that there and thank you for listening and you can find me on Twitter at uh Eev ISP A Nul A and uh my website is Avis uh Eevis dot codes.

So, yeah, thank you for listening.