I'll admit, I'm new to the world of accessibility. It's something that I had heard of and knew was important but I didn't actually know how to implement it.
If you're a member of twitter and most especially the tech twitter community you'll have seen the recent voice feature that's been implemented as well as the backlash it has received. If not, the new feature allows users to record a tweet instead of typing it. This is really cool, right? It allows people to diversify how they communicate their thoughts.
Well, the problem is, it excludes a whole community of users who have hearing difficulties. For platforms that rely on sound, there is usually an option for captions/subtitles so that no matter a user's situation, they can enjoy the provided content. So it is understandably upsetting that a global company like Twitter has left accessibility as an afterthought.
Simply put, accessibility is a necessity. As a developer at the beginning of my journey, these are practices I want to learn now, rather than correct later. I think it's important to have empathy at the forefront of the work you create because at the end of the day it makes a better product for everyone.
What type of developer do you want to be? If you're like me then join me on this journey to learning about web accessibility and learning how to implement it.
So, let's start from the beginning, what exactly is web accessibility?
In a nutshell, web accessibility is providing a web app for a user that, regardless of whether or not said user has an impairment, enables them to access the app's content without any difficulties.
"Surely, if a person can visit a website in the first place it's accessible". Well no, not really. A real-life example of this is where a wheelchair user wants to visit a restaurant because it's had such popular reviews and it advertises a 'No Booking Necessary' service. It turns outs, even though they can get into the restaurant, there isn't any seating area available for them because of the way the restaurant is laid out - all the chairs and tables are extremely close together. It should be obvious why this is a problem. A wheelchair user needs space to navigate around the restaurant before making it to and from their seat or the lavatory. Let's say they do manage to squeeze into a place, they're still not really able to enjoy the food because they're uncomfortable and the experience overall becomes a negative one. The head chef or restaurant owner probably never meant to discriminate against the wheelchair user, after all, they want everyone to experience their food. However, they did and whether or not the food was good it no longer matters because the overall experience and comfort for the wheelchair user were poor.
If you apply this example to an actual website, the 'No Booking Necessary' service is equivalent to saying "Anyone can use this site". The chairs and tables are the structure of the website. The food being served is the website's content and of course, the head chef or restaurant owner is the developer. Each and every part contributes to the user experience. There's an important lesson here. It's also a simple one. Try to think about and accommodate for all possible types of users who may wish to have access to your website. You don't want to leave a user frustrated.
Typically, there are many types of impairments people can have, and three levels of severity. An impairment, in terms of web development, can be classified as:
- Sensory (mostly vision and hearing)
- Motor / Physical
- Cognitive.
The severities in which they are categorized are:
- Situational (based on the current environment)
- Temporary (most likely stemming from an injury)
- Permanent (a continuing condition either from birth or through injury).
An app's accessibility can be implemented through focus, semantics, and visual design. Focus is typically looking at where the user is located on the app and how to help the user know where they are and what they are on. Semantics dives into how to logically layout an app so that it makes sense to a user who may not be navigating through the app in a 'traditional' way. The visual design aspect relates almost entirely to CSS. Can it be viewed on any browser? Is it responsive? Is there suitable contrasting throughout the app? Can text be read properly?
I'll be covering these topics in more depth in later posts once I learn more. For now, one thing to be aware of is some of the assistive technologies out there to help implement these features. Assistive technology includes but is not limited to screen readers, braille displays, magnifiers, voice control, and eye-tracking.
That's it for now! Here is a small list of some of the resources I (currently) have and will be using to understand and implement accessibility.
Udacity Web Accessibility Free Course
Top comments (11)
I think one of the most important points with accessibility is that it also improves general usability a whole lot! It makes you think about more stuff than just adding an onClick handler to things and calling it a day.
These things go hand-in-hard to make the web great and usable, but go easily neglected by far too many developers:
I've noticed that the more I've had to spend time with JavaScript the harder it is to keep up with most of these. When focusing too much on JS you kinda only do the #3 and the other parts get neglected. This has made me switch from React apps and SPA to traditional single script solutions in my hobby projects, because you simply spend too much time solving stuff already implemented by the browser when you go for the typical SPA road.
I can give a few examples how you notice the lack of attention to these in regular day-to-day development.
Unhappy path
A colleague of mine rewrote a part of CMS page serving so that instead of keeping only one page in Redux it kept each page there, allowing for better back/forward browsing. However while doing this he wanted to be strict (also a super fan of TypeScript), so he limited things so that the URL allowed only for the expected search params to be there and give 404 otherwise. This of course meant that all the pages that were in Google campaigns and links in all the customer facing emails started to give a 404. Simply because he considered everyone to have his happy path.
Focus
Our site still doesn't handle focus and interaction to the right part of the page on regular SPA navigation. There are all sorts of other fancy stuff like external link warning dialog, but somehow this kinda basic thing gets neglected. I guess I'll just simply fix this when I get back to work after my vacation.
Accessibility
This word gets spoken a lot, but it is so hard to actually maintain it! Sometimes I get back to a file and notice that some accessibility feature that was there before has vanished entirely in a refactor. And yes, this is due to having a lack of test coverage, but also shows how developing for minimal feature happy path and focusing too much on developer experience can be bad for end user usability.
Modals and dropdowns
These often lack tabbability control and too often focusing inside the modal or dropdown as well. Also restoring focus back to where it was when closing (when valid to do) is non-existant. Some of this has to do with having an old React codebase and there having been no accessible components when things were done originally, but convention and repeating things as they are often wins over thinking about what one is doing and how things should be done properly.
Lack of semantics, JS wins over HTML and CSS
Some devs only do divs. Others think that when they make a standalone form control it has to be within it's own form element. Then there are folks who don't look at resulting HTML elements at all and then you can find link elements wrapping list elements, links inside links, CSS-in-JS span elements that have h2 styles (and only the styles). If you want a perfect example of wrongness have a look at Twitter's DOM structure. Then try middle clicking a post open into a new tab (spoiler: nothing happens, because they decided to remake the web instead of embracing standards of the web).
I guess I could go on and on with examples of how things are wrong and how even the big players of the web get the stuff so, so, so wrong.
I'm with you on that! I'm currently working on creating a blog using just HTML & CSS so that I can get into the habit of practicing #1, #2, #4 and #5 more in my work
I have been working for several high-profile clients for accessibility for quite some time and writing many blogs about it. I actually started making some brute force compliance JavaScript stuff just for kicks to rapid triage a site and I thought that maybe somebody might make use of it and help contribute.
github.com/CodePosse/WCAG-Brute-Force
Thank you!
This is a great intro into the "why" and thank you for the list of resources! I also got a lot from the Accessibility in Javascript Applications course on @frontendmasters from @marcysutton . And, listening to Steve Krug about usability testing made me look differently at what's needed to make a site usable. Looking forward to the next posts in your series!
Nice! Thank you for this!
Good post I know bit about semantics but it is a massive topic there and this is definitely something I need to learn a lot more about. When I asked about resources a couple of people suggested this playlist youtube.com/playlist?list=PLNYkxOF... already learnt quite a bit of the videos I've watched so far
Oh yes! I came across this too! It's wonderful because each video is easily digestible!
This is great stuff Lopé, I'll definitely be following along and learning with you! Thanks :)
wooooh!