A short and simple post today, I want to know whether people agree or disagree with me on the sentiment of my question: why does accessibility have to be so bloody complicated and inaccessible? (W1y d2s a11y h2e to be so b4y c9d a1d i10e).
I especially want to hear from people who are new to development. Have you come across accessibility yet? Do you find it confusing? etc.
Start of my rant!
I mean accessibility (ensuring end products are usable by people with disabilities) isn't actually that difficult, it requires a breadth of knowledge but things are actually pretty easy once you understand them.
But...between using the least accessible way possible to describe the practice, (the numeronym a11y instead of just "accessibility") through to the horrendous task of trying to understand the Web Content Accessibility Guidelines (WCAG) why do we make it so difficult?
And if you don't think WCAG is hard to understand then see this answer I gave on StackOverflow to the simple question:
"Does using a placeholder as a label comply with WCAG 2?"
Read first: this is not a suggestion that you should use a placeholder instead of a label, more of a thought experiment as to whether a placeholder is sufficient under WCAG guidance. If you do use a placeholder instead of a label then your site is not accessible as I…
</p>
It shouldn't have taken me 1500 words to answer that question, the answer should be simple.
No.
(ironically I landed on "technically yes" which is unreal, read it and see if you agree!)
The basics are easy but we over complicate things!
I mean here is all you need to know to solve 90% of accessibility issues I see every day:
- Use semantic elements such as
<nav>,<main>etc. - Add
altattributes to images that describe the image in context. - Add properly associated labels to forms
- Don't skip heading levels on a page.
- Don't use poor contrasting colours - use a contrast checker
That is it! If you somehow manage to do those 5 items your site / web app / app will be 90% accessible.
If you are new to development then learning those 5 things will make you a better developer (in my eyes) than many "senior" devs who still use <div> soup to structure their documents!
And the best thing? You can learn all 5 of them in less than a day!
I mean don't get me wrong, the final 10% does require a lot more knowledge, but that is all, knowledge. If the documentation was easier I am sure more people would look it up and implement it.
Do you think we can do better?
So what do you think? Confused by WAI-ARIA, WCAG, ATAG, VPAT etc? I know that even now I can really get bogged down in everything, I hate to think what people just starting out learning about accessibility feel!
I am hoping WCAG 3.0 (formerly WCAG project Silver) will fix a lot of these issues but that is over 8 years away before it becomes the standard according to current plans!
"WCAG 3 is not expected to be a completed W3C standard for a few more years. WCAG 3 will not supersede WCAG 2, and WCAG 2 will not be deprecated, for at least several years after WCAG 3 is finalized." - source WCAG 3.0 Introduction on W3
So in the mean time I suppose what I am asking is: what would you like to see / do you need that would make it easier for you to learn / implement accessibility?
Oh and what do you think about converting the tag a11y to accessibility and making them synonyms on dev.to?
I look forward to your thoughts and ideas! Any good ones I will turn into a post / series!
/end rant 😋
p.s. I really struggled to find a meaningful cover image for this article, anyone seen a better one I can use for inspiration that isn't using the stereotypical "person in wheelchair" to denote accessibility??
Edit: thanks to @devlorenzo for finding an image that helped me pick a better one! ❤️
Latest comments (69)
Does wrapping IMG element in a div count for inaccessibility even upon adding text.
As someone newer to interacting with the dev community, when I saw "a11y" I thought it was short for Eleventy!
I got into this series from the 8th post and enjoy your work from what I've read so far.
Accessibility is something that I really want to make a point of doing. As someone who is neurodivergent and knows many other varying disabled people, I think it's up to me as a web developer to be the change I want to see. I thank you for these posts and I'm going to learn as much as I can and apply it to my work from now on.
Thank you for the kind words and I am glad you are finding my angry rants useful!
I have a series of posts planned on building the ultimate UI components so they will hopefully be really useful as there will be a lot of explanation on why I do certain things from an accessibility perspective.
It warms my (cold 😜) heart that you are pushing to learn accessibility and your attitude (I must make the change I want to see happen) is exactly what we need to fix the web so it is inclusive! ❤️
EXACTLY! This is the bit I am really going to be pushing down people's throats in the next few months, there is money in accessibility!
As a developer I have noticed that most web sites out there fail when supporting the wide range of people who are meant to get into the accessibility standard. Why?
I really want to believe that it's due to vagrancy on our commitment. But the real fact is that must of us rely on third party software to develope web sites, apps, software or whatever.
Take an easy example. If you build a web site using WordPress, you probably are using a template which code will be away from your easy manipulation without installing some plugins and plugins of that plugin (yeah, Elementor, I'm looking at you). So, it would be an extremely hardorous a task implementing accessibility if it was not included by the developers who built our framework of choice.
That's my humble opinion.
You see this one is a bit of a chicken and egg scenario.
People don't demand accessibility (because they are unaware of how much inaccessibility is hurting their conversion rates etc.) so developers who know nothing about accessibility build website themes.
Then the people who do care / wake up to the business impact of accessibility have a really hard time finding a theme that is accessible (I have yet to see one, loads that claim to be, but often are not and what they really mean is "scored 100 on Lighthouse or Axe" - which I suppose is a start at least!
If everyone insisted on accessible websites then fewer developers would have to learn the detail as the hard parts would be handled automatically....hence chicken and egg!
It isn't vagrancy (on the most part) it is lack of motivation (you might want to make things accessible but your boss does not care and doesn't allow an extra few minutes for it) and lack of education (I mean, their can't be that many people using screen readers / with vision impairments surely?).
It is the same argument we see with supporting Internet Explorer. "But there are very few people using IE in our visitor logs"....well of course not, they have already come to your site, realised they can't use it and gone elsewhere.
Same with people with disabilities "We don't have any disabled customers" - are you sure, I mean, how do you know that (most disabilities are invisible) and secondly same principle - of course you don't if your business is not accessible, they are off spending money with your competitors who are accessible (or at least make the effort).
Ahhhh - I am ranting again, must stop!!!! 🤣
Thank you for the comment, it yet again points us to the same major issues and helps focus my thoughts on this.
I think because I'm a newbie developer and have just started really learning about web development pretty recently, I already knew about the accessibility issues in web development pretty early on in my learning journey. When you learn about HTML5, you learn a little bit about accessibility and, eventually (if you really care about what you do), everything else that comes with it.
I guess the hardest part about learning how to make your website accessible is that a "non-accessible" website and an accessible website is pretty much the same thing to a person like me. I wish there was a way we could outright tell developers "Hey, this isn't going to work. I know it looks like it's working, but it won't work and here's why." I know Chrome Lighthouse does that pretty well, but not every developer knows tools like Chrome Lighthouse exist. (I guess I'm kind of describing a superpowered IDE at this point that goes "Error: your website is inaccessible." every time you write code that doesn't follow the accessibility guidelines.)
The best way to learn accessibility (and by extension build much better products) is to learn how to use a screen reader.
NVDA is free for Windows or if you use a Mac you have VoiceOver ready to go.
It takes about 30 minutes to learn the basics and within an hour you know a lot of the core commands.
Try anything you build with it and that will soon give you your answer to whether something looks like it is working vs whether it is actually working.
I am not saving that solves the issue of knowing how to fix it, but at that point you can ask a question here or on Stack Overflow with the [accessibility] tag and I / others will be able to help (normally me on Stack Overflow 😋)
There is a great plugin for Chrome called Accessibility Insights - a little complicated at first but it will guide you through loads of tests and is a great way to learn about logical focus order, keyboard traps and all sorts of other things that sound complex but are actually super simple (yet again, back to my original point in my rant that they are simple but finding the information is difficult!)
Thank you so much! 🙏 This will help me tons. I rely a lot on Chrome Lighthouse, didn't know NVDA and Accessibility Insights existed.
Also Lighthouse is powered by Axe on the accessibility front - Axe can be used as a plugin you can use straight from devtools (it is much easier to use as you can highlight the affected elements etc, although they do point you to WCAG for solutions!
Nitpick:
Your list of five easy things to do is nice, and is an awesome starting point, but it falls far short of the ‘90% accesible’ watermark that you claim for any reasonably complex application, especially once you take into account the lack of practical useful support for some semantic elements (with the dialog element being the most problematic offender here).
Given this, I would extend your list of easy steps with two others:
roleattribute. For anybody who is non-visual and/or uses keyboard-only interaction with the web, this actually will solve a significant percentage of accessibility issues on it’s own. It’s also one of the simplest parts of WAI-ARIA to understand, is well supported across browsers, and even sometimes makes things behave better for ‘normal’ users as well.Nitpick away, I welcome it!
I think 90% accessible is poorly explained on my part, 90% by volume, not by impact / severity would still be reasonably accurate (as I assume once you learn those items you actually use them!).
point 1
roleattributeI can't agree on your first point. Not because I don't agree with the sentiment of using the appropriate
role...far from it!The reason I can't agree is because the second you add
role=you open up the whole world of needing to addariaattributes, expected keyboard functionality etc. (mayberole="alert"androle="search"are the only ones I can think of that you can just use out of the box with very little knowledge)Plus the second you give people the "power" of
role=you get the disaster that is hyperlinks as buttons, divs with roles instead of native elements etc.It is also the very first thing that is a "code smell" to me...I see a load of
role=s in the HTML and I think "if only they started with x element they could have saved 20% of their extra code".One more thing is that majority of
roles are mirrored in semantic markup. Very rarely do you actually need to stray from semantic markup, we just like to (prime example being custom<select>elements due to how little flexibility we have in styling / content - one of the few times when I can completely agree that "starting with native" just isn't feasible if you have anything even marginally complex to display!).Finally the second you learn of the role attribute you also learn of the
role="application"and as we know....that might as well burn your application to the ground for people who use a screen reader and or a keyboard! It should come with a public health warning for the majority of developers! 🤣Along the same lines, the
dialogelement example. Yes it falls far short of "set and forget" but it is still better than just<div class="dailog"as you see in soooo many applications and should still be used as a base for a modal in most circumstances.point 2 - browser zoom and font sizes
Second point - oh that is without doubt in the top 10, in fact I would have a hard time arguing it not being point 6 or 7!
I am not without this sin either unfortunately, I have a couple of older sites that are still live and out there that use
vwfor font sizes....and it does make me cringe that I did that!So I would probably put this point 6 or 7! But luckily nowadays a lot of the "stopping zooming" has gone away and a lot of browsers override this anyway so not as bad as say 5 /6 years ago.
My number 6 (before you mentioned zoom and fonts 😋)
Personally my number 6 would be to learn how to use
aria-label,aria-labelledbyand visually hidden text.Those three items can massively improve user experience when implemented correctly and fix a lot of the empty button and link issues we see.
My number 7
Learn native HTML 5 form validation.
Yet again faaaaar from perfect, but much better than nothing. Plus it does act as a nice base for proper validation through progressive enhancement.
For the
roleattribute specifically, there are definitely some things you should not use, and semantic HTML is always preferable, but stuff like hyperlinks as buttons is unfortunately here to stay with or without this, and it’s arguably better to handle those correctly but still have them than to not handle them correctly as a way to discourage developers to use them.As far as which roles to actuallyuse though, tagging the landmark roles (
main,navigation, and similar stuff) is easy, needs no extra attributes, and immediately makes your site more accessible for most (but not all) users using modern screen readers.On the note of the
dialogelement, needing a polyfill just for support on major browsers (Safari completely lacks support, Firefox requires running the nightly or manually enabling the element inabout:config, and Edge has only supported it since January of 2020) is a major complication for practical usage, especially when said polyfills often require special handling when used with popular application frameworks. Yes, using the native element is preferred where possible, but usingrole="dialog"is still better than nothing, and there are a distressing number of sites out there that do nothing beyond making the element look like a dialog in visual presentation and hijack any input that would go to other elements on the page.But with modern screen readers
role="main"is exactly the same as<main>. It is an overhang from xHTML / HTML 4 days....but we have had HTML 5 for 13 years, there are few screen readers that don't support it, even legacy ones that only run on IE9!I mean we could take it to the extreme and say "but what about people on IE6,7,8" in which case - sure add the
roleattribute to those elements, but i guarantee there are 100 other things that make your site completely unusable to them when using HTML 5 that make it futile.I cannot think of any standard landmark role where adding
roleadds any benefit over its native HTML5 version.Now with that being said I do agree with you on
dialogbut as I said, you then have the problem of needing to knowaria-modal="true",aria-labelledby, add keyboard functionality, focus management,aria-haspopupon the button that opens the modal etc. etc.We are a long way from the stuff that beginners can learn in a day. That was the point I was trying to make,
<dialog>requiresrole="dialog"still due to poor support to inform screen reader users what element they are in, but it makes no difference if you don't know the other things you need to implement!I would rather you learned
<dialog>so that 50% of users get some semblance of a usable experience instead ofrole="dialog"which would add 0 functionality but would let a screen reader know "hey this is a dialog, but that is all, we haven't made it usable or anything".If you have a particular example in mind of whether you think knowing
role=""is useful over knowing the semantic equivalent I will probably agree entirely but I can't think of one that doesn't require a much larger breadth of knowledge.So that leaves
role="alert"androle="search"as the only two I can think of that are useful without deeper knowledge? Maybe I am missing one though.As for everything else I think we are in full agreement, and as for how distressing it is seeing some modal implementations I think you under played the problem if anything!
My favourites are still the ones where you can't focus the close button (as it isn't a
<button>but instead<div role="button"where the developer didn't addtabindex="0"!) and of course there is no Esc key to close. I mean you know a problem is wide spread when WCAG has the "no keyboard traps" criteria in it!The things with dialogs though is that you don’t have to understand why you need to have
aria-labeledbyor any of the other functionally required attributes, just that they need to be there. That kind of knowledge (you need to have this so that things behave properly) is not difficult for most people to learn quickly provided you present it correctly, even if the ‘why’ aspect is much more complicated and harder to understand.As far as zero-effort role attribute values, the top of the list is probably
role="presentation". It shouldn’t need to be used, but a lot of sites do stupid things that involve using elements for purely presentational purposes without tagging them as such. Other than that,descriptioncomes to mind, as it’s dead simple to understand when to use it (if an element is pointed to by anaria-describedbyattribute, it should have thedescriptionrole).A handful of cases are not reasonably usable without specific additional attributes, but the required additional attributes are pretty trivial to understand.
progressbaris probably the best example of this, you just need anaria-valuemaxset appropriately and anaria-valuenowthat gets updated as you adjust the progress bar itself, and not doing this makes an application difficult at best to use for non-visual (and even text-only) users.I agree with you, but I think we have strayed back into the whole point of my rant now though.
If we made it simple "This is the skeleton of a dialog, you need these roles on it, these attributes, this attribute should be this, this or that" etc. Then accessibility would fall into place for 95% of things.
Where I was arguing the point was purely on what order I would want people to learn things that is all (and the overuse of WAI-ARIA due, mostly, to improper HTML markup!)
100% yes I have no idea how I didn't think of
role="presentation"...possibly because I use it so rarely.Where did you read / learn that? I don't think
role="description"is a real role?Are you meaning
aria-roledescriptionwhich is for custom elements?aria-describedbyis intended to be used to add additional long form information to a control, input label etc. But all it expects is the ID(s) of any element(s) with readable "flow" content inside it. It does not expect the element it is being pointed at to be marked up in any special way (unless this is a future aria thing I haven't seen!)Same again with progress bar - easy to understand....but knowing about it and using it....that is where my rant started!
I think this is great that there is a Lighthouse plugin that can assess the accessibility level of our websites but I feel like this is not enough.
Either we need a tool that is cross-browser (a plugin that can integrate not only with Chrome but also Firefox and Edge and in term every browser) or something that is part of the standard and that can opt-in be enabled to check that our page is accessibility ready, with some tips and links to web pages that explain the why and how.
I am by no mean an accessibility expert, but I would not mind at all having some tool that tells me that I didn't put an
alton myimgtags or something like that, like a linter but standardized so that it is easily discoverable.Not sure if I'm being clear here but that is what I think accessibility tools should look like.
You see there are loads of plugins that catch about 40% of accessibility errors, but you have to know to look for them in the first place!
There is also the "accessibility" tab when you are in developer tools inspecting elements but that looks quite scary when you don't understand it (but yet again it is actually really easy to use).
Also you may not know but if you right-click and inspect some text in Chrome it will often show whether there is enough contrast if you click on the colour picker next to the colour of the text.
As you can see there are loads of tools to help....still the same problem though, you need to know about them and understand the basics!
Plugins
One plugin that I love is Accessibility Insights for Web from....(* drumroll * Microsoft of all people!)
It is, however, quite complicated at first but it covers things like a test for "logical Focus Order".
Another one that is good is the deque Axe plugin, not quite as in depth but easier to use. This is what Lighthouse uses to assess the accessibility of the site (but they do leave a couple of tests out) but the way you can inspect elements, highlight them etc. is much easier in the Axe plugin. The down side is that when there is an error the explanations of what is wrong can be complex and often point you to WCAG - which is where most people give up!
The main problem with plugins
The main problem though is what I said in the first sentence.
Plugins only catch about 40% of errors. This is why the resource / education part is the bit I think needs work as accessibility is a subject that is "shallow but wide", nothing is complicated in of itself but the amount you need to know is too much for most people.
What do I suggest for beginners and professionals alike?
If you really want the best and easiest way to test accessibility and learn quickly why it is important - learn to use a screen reader. (NVDA is free for PC users or on Mac you have VoiceOver built in!)
It might take you an hour to learn the controls (much less for the basics!) but then you can just fire a page up and use it, that is the real "eye opener" for a lot of people and is still the way I recommend testing.
Thank you for your answer. That look scary indeed! A screen reader might be my best bet.
Do you happen to know any good one on Linux for instance?
Actually I don’t I am afraid.
I know Orca used to be the go to Linux one but nowadays I am not sure if there are better options.
I'd totally support that😂😂. While I've been creating sites for a while, only recently I started looking into accessibility. And I can say, I was fcking confused by a11y.😅 So yeah, if we want things to be accessible, we should start at making the topic itself clear to understand.
I'll see how far I can get on my portfolio website with these. If I get stuck I'll be in your DM's like:
Haha DM me all you want, I have set my DMs to "open to everyone" and I would be happy to help!
If one more person agrees on the "a11y" thing then I will start harrassing the dev team to get it sorted 🤣🤣🤣🤣, I am glad it isn't just me!
Aight then!
Just do it!🤣🤣🤣
I agree with every single word of this. 💪
When I said it was easy what I meant was once you understand each element and attribute and why it is relevant you can put stuff together in a few key strokes.
I admit I think I did underplay the "knowledge" part - but that is I suppose my point. When starting out you don't need more than the basic knowledge of those 5 points, what you really need is a resource that goes "trying to make a custom select, here are 3 skeletons you can copy paste and here is what you can and can't do with them". I mean, I know it would still result in some mistakes but I think it solves the "overwhelm" that puts so many developers off.
Some of the comments here have made me realise that perhaps we are heading in the wrong direction because there are now more and more frameworks. I could give you a React example of how to do something but if you are new you aren't going to understand how to implement that in Vue or Angular.
The final nugget of wisdom you said there was "keep it simple" - the amount of times people start using ARIA to add
role="navigation"to a<div>instead of just<nav>...is it any wonder people "switch off" to accessibility! Not sure if over use of WAI-ARIA is HTML 4 legacy or just that there is so much erroneous information out there!There is that much erroneous information in the WCAG/WAI documentation. I found a thread on github where they have been arguing about whether a navigation menu is a real menu since 2017!
They all pretty much agree that navigation is not a menu - BUT THEN SHOW ME THE CODE that JAWS will read AND works with the keyboard AND creates an intuitive menu for sighted users on different devices.
Are any of these people developers with actual work to do and actual projects with actual deadlines?
I mean I want to make my (internal) site inclusive - but make it easy so I can actually do it.
Don't get me started on the kb of dependencies for simple projects thing, I will have to get my soap box out and start preaching if we go down that route 🤣🤣🤣
Learning the fundamentals is indeed essential. But if everyone did that we wouldn't have thousands of frameworks to choose from!
But hey, what do I know, I am one of the tailwind "haters" so maybe I am just old and out-dated!
Yet again the big issue summed up in one nice sentence:
It is so difficult to teach yourself about accessibility due to the amount of rubbish information.
I mean there was a post a couple of weeks ago singing the virtues of "Fully accessible Menu components"....I found 5 issues in 2 minutes so how can anyone know who to believe?
Preword: this comment is not a reflection on your article, it is really well written and thought out, this is just a warning on believing things are accessible when they may not be!
"Fully Accessible"....the accessibility of this is questionable at best.
Why aren't they using an
<ul>and<li>for the list of buttons so that screen readers that don't supportrole="menu"still get a count of options?Why are they using
role="none"on a div, when it has no role in the first place.Why do they stop you tabbing out of the menu when it is open, that is not expected behaviour?
You should be able to cycle through all items that start with a letter (so if you press
dit should go to "duplicate", pressingdagain should go to "delete"), which it does not do, it stops at the first item (which can be very confusing).Similarly if you are on the first menu item pressing up arrow should go to the last menu item. If the focus is on the last menu item pressing down arrow should move to the first menu item.
Anyway - there are probably other issues, by the time I found all of the above I had seen enough!
Oh and WAI-ARIA is your last resort, support is not as great as you may think, even for basic WAI-ARIA attributes, which is why semantics such as
<ul>are so important!Then the "good" information is unreadable and difficult to understand and....we are back to my rant! 🤣🤣
Sorry I always forget the comment doesn't link to the article (which is really strange!)
No they didn't respond, but it wasn't there fault as someone pointed out, they were just reciting what the devs who built it said. But that is what I mean, people build echo chambers very easily that spread incorrect information and it just escalates.
Oh I agree, I don't want to put people off posting, the more people talking about accessibility the better!
The problem is I often get comments deleted when I try to help (perhaps it is just my writing style is quite "direct" so comes off as attacking and harsh 😋).
Plus there are loads of sites where I can't comment so how can I and others "warn" people that the information is incorrect.
True contact form could be the way to go!
As for the comments I am actually thinking I might suggest a tag "#comeAtMeBro" which lets people know you are open to criticism in the comments 🤣 (I am kind of serious but a different tag obviously...you might see a side post on that later now I think about it!!!)
I have been desiring to learn more about accessibility, but I do feel a bit overwhelmed by everything. As a hobbyist it isn’t a huge priority but it would be a good thing to learn.
That right there sums the problem up in 2 sentences! I don't think I could have described the issue any more succinctly than that, thank you! ❤
If you feel so overwhelmed that your response is "it isn't a huge priority" then the whole ecosystem has failed you!
You see hobbyists like yourself often end up building better and better products, sites etc. out of necessity.
Those sites may have thousands of visitors one day and as such we still have a big divide between the "haves" and the "have nots" when it comes to access to information.
By the time you "have to" think about accessibility (which technically is day one under the laws of most countries! But the risk of getting sued is not a concern for hobby sites so you don't have the law as an incentive sadly!) the damage is done and you have loads of bad habits you have to unlearn.
Also we need to make it much easier for new people / hobbyists like yourself as you will always see accessibility as "something that I have to do" and a chore instead of "for the sake of 10 seconds extra work I can make sure my site includes everybody" and a joy / something beneficial to your projects.
The problem is it is 10 seconds of work but months and years of knowledge and that is why we are in this mess!
What would be the "balancing point" for you where we turned accessibility from "something nice to do" to "something I am happy to do" or better yet turn it into a priority for you?
I suppose for myself, a short good quality course or walk through is most desired.
I understand the purpose of accessibility, so I am less concerned with theory and more concerned with practicality and how do I best implement this? I remember some of the things I read before being like “you should do x, y, z” but telling me to do something and showing me how to do it are not equal.
Like how do I make an onClick dropdown menu accessible to an individual who solely accesses the internet with a keyboard? Maybe I really haven’t looked into it enough 🤷♀️. I do remember looking into this area around 5 months ago wishing more of the information was as straight forward as learning React or CSS grid.
That is good to know, I think the lack of simple to understand examples has been a running theme through this thread so I will definitely be looking at addressing that!
I doubt we could do a short course due to the breadth of the subject but a “bit sized” course where concepts are explained in a granular fashion might be more easy to pick up and keep diving into and less overwhelming!
Thanks so much! ❤️
Thank you for being so willing to address this area!
If you create a course, I would definitely be interested in learning from it.
I am pouring lots of resource into it at the moment, so I will endeavour to remember to tell you if anything applicable gets released you might find interesting!
Thanks for the invaluable feedback! ❤