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...
For further actions, you may consider blocking this person and/or reporting abuse
About the a11y, I personally prefer "accessibility".
Motivation
Honestly, I think the biggest issue at the moment is that a lot of businesses and developers don't care about accessibility and aren't even aware that they should care. I imagine if that is sorted, everything will improve for the better naturally. At least, with new laws and accessibility lawsuits targeting large corporations, people will slowly begin to care.
Another issue is design. We don't have labels on forms and stuff because we think it looks worse. But it makes usability worse for everyone, not just people with disabilities.
So I think the first step is to understand the problem and provide real motivation for it. I also think that the motivation has to be targeted at businesses. I.e. profit or prevention of lawsuits. Because it's businesses that employ us and will demand that we know particular things or not.
Resources
For the most part, I think accessibility resources that exist today aren't too bad. I just found them a bit scattered at first.
Some resources are good for the basics, but don't cover enough (in my opinion). For example:
I think the WebAIM resource is very good for learning, quite thorough and also has a quick checklist for accessibility work. But I didn't discover that resource for a while.
So my learning would have been more efficient if I had a good learning guide to start with, on what resources I should look at depending on how deeply I want to learn accessibility at this time.
Even better, it would be great to have a centralised resource for accessibility like what OWASP is. OWASP has the cheatsheet series, which is great for learning the basics of security as a developer. It has tutorial programs and such. It also has links everywhere for more information on specific topics.
Move accessibility workload into its own layer
Frameworks and programming languages handle important security concerns automatically. E.g. frameworks prevent (or warn you) from outputting raw HTML to the screen that came from user input. They provide mechanisms for authentication. Etc.
That work is removed from the developer and put into the framework, or the third-party service (e.g. Auth0), or the library (e.g. passport.js).
It would be great to similarly remove some of the accessibility concern from the developer and put it into its own layer.
That's how software keeps improving in general. We have layers built upon layers. Each layer is a separate concern that can be handled by a different team. That allows more layers of abstraction to be built on top, allowing us to do more with our software.
Anyway, these are some of my thoughts on the topic. What are your thoughts, disagreements, feasibility of these things?
I've been using the term inclusivity instead recently. I find it encompasses more of what I want to achieve, including layout for neurodivergent.
Well as our company name "InHu" stands for "Inclusivity Hub" I can't really argue with using inclusivity! 🤣🤣😋
I only stick with accessibility in my articles as inclusivity also encompasses things like race, gender, religion etc. so I like to try and draw that distinction!
Motivation
That is the area that I have been working on.
I think you have probably hit the nail on the head when it comes to root driving factor.
The thing I find perplexing is that there is a wealth of evidence and information that points to accessibility equalling profitability but we still fall backwards.
As for labels on forms that is why I was wondering about splitting things by role. Designers may not like labels but good designers can work within restrictions and it ends up with creative solutions. If we said “designers, this is your responsibility” we could solve the game of “not my problem”!
resources
I think I agree the information is out there, but as you said it is a minefield (and when you get to “non standard” widgets / custom elements it is very difficult to know what is relevant) and very scattered.
The learning guide is an interesting point, yet again something that a few people have done a post on but perhaps something that has never been fully “roadmapped” for people. I will have a think on that!
As for the centralised resource....watch this space 😜
accessibility as own layer
I like this principle, however I think the reason we don’t see this is that it requires HTML, CSS and JS to work in harmony. I yet again think this is a great idea but can’t quite see how we could abstract it without creating a very opinionated library / platform (but that might be the answer!)
Great comment and I think you made some really interesting points I will have a think about! Thank you so much!
This - to me - is it! If we put aside the morality of deliberately ignoring a section of society, and look at it from the perspective of someone that - for example - just wants to make as much money as possible from their e-shop, then why would you not make it as accessible as you possibly can?
Some shop owners may say that their target market (ski / climbing equipment, or bicycles, for example) is not those requiring assistive technology, but those people have husbands / wives / partners / children / siblings / parents / friends too: people who may well be the target market.
And sometimes, accessibility is not only about those needing extra technology. Sometimes, the specific target audience have stressful days, or they are distracted, or it's sunny and not easy to see the screen... all kinds of reasons.
Bloody hell, even if you don't care about the 'soft stuff' like morals and rights 🤦, you must care about making more money, right? 😀
It is really interesting to have someone recite my view on it so accurately. In fact I am not one who gives much credence to people who try and get accessibility enforced using the "soft stuff", as if society cared about morals and rights we wouldn't have so many issues in the world! 😋
I actually have a calculator I use as part of pitching for work where I show how quickly accessibility can pay for itself, especially when baking it from day 1 as part of the spec adds maybe 5-10% in costs (and that is for something complex).
I might do a post on that calculator actually, as it may help a lot of devs who sit on the "soft stuff" side of things persuade their bosses that they can easily get clients to pay for the extra work.
In fact you made me wonder if I should share all of my "secrets" now that I am taking the company in a different direction such as how I convey the scale of the market opportunity and the knock on effects of how making a site accessible can have huge benefits to a business.
For example people with disabilities might not be able to go anywhere else (as your competition's sites / premises are not accessible) and so will come to you.
Sounds harsh when phrased the way I put it but I portray it is a kind of "forced loyalty". As it costs a lot more to acquire a new customer than to retain a customer and upsell to them this is one that really makes business owners sit up and listen.
Then I point out that the disabled community is close knit and so one person can effectively give you loads of free word of mouth advertising as they found the one site where they can use it and it is a pleasure to use rather than a chore / impossible!
Is that something you think would be interesting, a "how to get key stakeholder buy in for accessibility" from my very clinical and cut-throat perspective? 🤣
Absolutely! I'm sure it would be far better than my exasperated, "Do you WANT to make more fckin' money or what!?!" efforts 🤣
I will add it to my writing schedule (now I finally have one 🤣), it might be a few weeks but i will (try and remember to...) let you know when I post it!
My pleasure. Those are just some thoughts for now. I'm interested to see how your work on this topic develops. Keep us posted :).
I truly do mean it when I ask, what do people think we could do better? More examples that apply to the real world? Documentation split and organised by job role (something W3 have been working on), free online training courses that do more than just recite WCAG back at you?
Whatever it is, let me know, I have been working on a product for over a year that should really help drive awareness but I want to add parts to it that make it useful to my fellow devs, so I want to hear your thoughts on what makes accessibility difficult and why you think we are moving backwards not forwards in this area of development!
Recently I was refactoring some frontend code and discovered some attributes on a custom progress bar one of our designers had made. I had no idea what they were, so I googled them and discovered were for accessibility. They allowed the tools to understand that it was a progress bar and how much progress had been made.
After reading about it a bit, I thought we could simplify our code and potentially have better accessability results by removing a bunch of our calculations that converted it into 0-100% and passing the values directly through.
I must have searched for half an hour trying to find something that would interact with the resulting HTML. I really couldn't figure out how to actually interact with those values. Finally the lady I was pairing with figured out how to configure the computer-to read the screen (this was computer-wide, it was even reading my terminal to me). So we turned that on, watched a tutorial to figure out how to interact with it, figured out some configuration to make it less annoying, and finally over an hour later, got it to focus on the progress bar and listened to the old and new descriptions to confirm that yes, the new values were an improvement.
Point of this story is that, despite some of the early commenters proposing that devs don't care, it's less about that, and more that it seems somewhat opaque and is extremely inconvenient. I definitely almost threw my hands up several times and said "whatever, it's good enough the way it is".
I don't think I have any amazing insights, but some aspects of my perspective may have value, so I'll list them out. Sorry if others have already mentioned these, I read about 20% of the replies, but there were a lot of them. And sorry if my issues are obvious to someone in the know, I'm not in the know, so just describing what it's like from where I'm at.
The story you told is mirrored in a lot of comments and when I think back, my own frustrations trying to learn the subject.
The thing is that point of "I almost threw my hands up several times" - that is where most developers then see accessibility as difficult, time consuming and think "there can't be that many people using a screen reader so why should I bother.
I do not think there is a single developer who has gone "I don't care", I think the problem is "I care, but I don't know why I should care and doing something about it is just not feasible within current time constraints".
I have been guided by the comments so far to suggest we have a library of "skeletons" for components. With brief explanations of each property and why they must be there and what options they take. Similar to API documentation (you know, it tells you 80% of the story but there are always some "gotchyas!" 🤣)
Your two points are interesting at the end, the different way of learning (which to be fair is much more towards the way I learn - let me play with it, let me break it, let me put it back together, just guide me as I do it) is one I need to consider on how to get the balance between "impossible to set up" (i.e. having a live sandbox that checks your work....too complex) and "not useful" (i.e. just some static text with "do this" written next to it).
You are certainly correct on the opaqueness....I mean that is where my rant comes from in that I answer the same questions that people could easily understand, but it is so difficult to get the answers they are after as the info is either buried in the thousands of pages of WCAG or on some random blog that you may or may not be able to trust!
Thank you for all of the points, I will go away and process them.
p.s. I have given a couple of comments here that point to tools that are useful to help you find and learn about accessibility issues. Have a quick look through for links you want "Axe" and "Accessibility Insights" or just look them up on the Chrome plugin store. As for screen readers - on Mac you have "VoiceOver" built in and on PC you can download "NVDA" for free. It takes maybe an hour to learn the controls to a level where you can use them....give one of them a go on your site - that is the best test and the biggest "eye opener" ever!
This video is awesome: youtube.com/watch?v=3f31oufqFSM
Yeah I watched all of the W3C videos - the problem is they go “here is something you really should know about” then kind of stop short of explaining exactly how to fix it.
We need a: Accessibility for dummies
I am surprised that nobody has done that (I literally went to look for it when you said it 😋).
Agree 100%!!!
I actually looked into it, you have to get a literary agent involved as the publishers of the "for dummies" series won't take direct / unsolicited ideas.
Maybe one to add to the 10 year plan at my side as it seems like a lot of hoop jumping 😂
Well that sounds like a hassle.
We gotta create our own version: XYZ for noobies😅😜
I can't believe there isn't a Developer's Guide for JAWS. In other words "What the heck do I have to do to make JAWS say 'abc' when doing 'xyz'.
And when do these issues become bugs in screen readers instead potholes for developers? Why can't screen readers read icons added using CSS? If I can see them while inspecting the code, why can't JAWS read them? Why doesn't the screen reader tell the user a link goes to a new site or opens a new window?
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!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!!!)
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.
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!
Your 5 points are solid, but when you want to go beyond semantic elements, things instantly get complicated. A custom dropdown (select) menu is the classic example. Why does a role element have to be the direct child in order to be valid. As long as it is a descendent, shouldn't that be enough. Screen readers having inconsistent behavior when content is dynamically updated. Personally, when using newish APIs (Grid /Flexbox for example), I find it time-consuming and hard for my markup to be valid, be described properly with screen readers, work consistently with a mouse and keyboard and fit a tight UX design.
That is the point and I completely agree, you want to create a custom select, be prepared to spend hours learning
ariaattributes that you are also very likely to get wrong. One example will usearia-haspopupand the next will not have it and you have no idea why?I think what makes it worse is that you can even do everything right and still get it wrong!
For example:
Now that is perfectly valid and correct use of WAI-ARIA to create an area where you can add status updates etc. and they will be read out by the screen reader.
The problem is that the aria-relevant property is not well supported by browser / screen reader combinations.
What aria-relevant is meant to do is look at the contents of an
aria-liveregion and say "I have seen that before so I won't read it again" so that it only reads amendments (I am simplifying it as there are different behaviours ofaria-relevantsuch as "additions", "removals", "text", (and combinations such as "text additions"! Yet again complicated!) but that is the basic gist of it).What happens in the real world is that the whole contents of that
aria-liveregion will get read out each time you add something to the region. Which is horrendous.So do you follow the spec or do you replace the content of the
aria-liveregion each time to avoid this?You have made me think that we need a "caniuse" for
ariacoupled with some simpler examples that are a bit more opinionated (e.g. "use this as a skeleton for your custom select, you can add this content in here and you need this JS for the functionality. Here are 10 things to check once you have added your content...").It would strike the balance between "ease of use" and "flexibility".
What do you think?
Your caniuse suggestion would be well received I imagine, i've spent a lot of time on that site. tbh I hadn't come across a11ysuport.io before and looking at all the reds and yellows it doesn't surprise me why it is so complicated to get things consistent with the patchy support across the board.
For most of my UI components that use things like custom dropdowns, I provide a semantic alternative that the browser can render. All I want now is an API that can notify my code there is a screen reader being used so these semantic components render by default.
The best solution I can offer is to have an accessibility settings screen that lets people select their input method.
A lot of work initially but that is what we have added to the new site we are launching. It also allows you to put settings for colour contrast (allowing you to offer low contrast for people who are sensitive to high contrast!), different functionality etc.
You could pick up some screen reader users by listening for pressing "1,2,3,4,5,6" and then having a message that is in an
aria-liveregion that says "it looks like you are using a screen reader would you like to enable a screen reader friendly mode.....etc.".Alternatively you could have an option appear when people press "Tab" before your skip link that lets them switch to native elements mode?
Obviously they are all hacks but one of them might work for your use case?
Oh and yeah - the support for accessibility is a nightmare, especially when instead of just having to test in 3/4 browsers you have to test in 3/4 browsers with 3/4 screen readers - it just isn't feasible for 99% of companies (ours included and we eat, live and breath accessibility!)
Already doing the toggle component button which comes just after the "skip to content" button but I love the idea of listening for number presses, is that behaviour consistently used by screen readers? Any other signals that we can infer that a screen reader is being used?
Numbers are used by NVDA, JAWS and VoiceOver for jumping between headings (actually you should also listen for "h" for "next heading" thinking about it!)
Not 100% fool proof as some people may prefer to navigate by links or sections (using different shortcut keys) however it is the preferred way by most people and “unusual” enough to infer their are using a screen reader.
maybe listening for left and right arrow keys would also work as those are used heavily by people who use screen readers but not so much by people who are using the keyboard without a screen reader.
The problem comes with screen readers on mobiles and touch devices, potentially could listen for double taps and swipes being used but it wouldn’t be very accurate and I am not actually sure whether those commands are intercepted by the screen reader or still bubble through to the page (I would imagine they are intercepted), never really thought about it until today so all of these ideas are just me "spit balling", they could be completely rubbish! 🤣🤣
I think your current solution is the best option (next to having a settings menu to aid discoverability) at the moment though!
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 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!
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! ❤️
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 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! ❤
At Unsplash: unsplash.com/photos/jiNgKqKW5W4
I like that actually! Thanks!
What do you think?
Made me go towards “complicated” rather than accessible. Thanks I choose a better cover image and the inspiration was perfect!
Sure, the interesting thing was to play on the accessible / complex comparison. That is, how web accessibility is actually complex inside. I associated it with the feeling of being lost due to this complexity. The hand represents the last hope, the last chance to be saved from this complexity and therefore to understand accessibility. Which is opening and reading your article.
But yours is fine!
Like I said, I saw immediately what angle you took and it made sense. I was just “stuck” on trying to show accessibility and couldn’t see other angles! Was much appreciated!
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!
Does wrapping IMG element in a div count for inaccessibility even upon adding text.