🤷‍♂️ W1y d2s a11y h2e to be so b4y c9d a1d i10e? 👿

I've been using the term inclusivity instead recently. I find it encompasses more of what I want to achieve, including layout for neurodivergent.

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!

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 truly do mean it when I ask, what do people think we could do better?

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.

• Most devs and most of the people that prioritize effort do not interact with accessibility in any obvious way. And when they want to, it is unclear how to do it. It's not clear to me that accessibility should only be for disabled people, so if our tooling was able to use this information in a way then it would be visible to us, and we wouldn't need to go on a tangent into a domain we're bad at to do a bad job, just because we know we should. Like if accessibility were more accessible to developers, then that would greatly reduce the hurdles we'd face, and if it were so accessible that we actually used these features, then people would likely notice and fix those issues without prompting.
• One way that I maybe differ from other devs I've worked with is that I rely on introspection much more than documentation. If I've got some object, and I am trying to figure out how to get it to do something, it's usually much easier to ask "What methods does this object have? Do any of them sound like what I'm looking for? This one sounds promising, what's its signature? Okay, let me try calling it and see if it does what I want" than it is to figure out what to do by reading documentation. At least for me. One reason accessibility is difficult is that I don't know how to introspect on it. I don't know how to ask "what semantic tags could I use here?" or "what attributes could I put here?" It seems like this info is scattered across an unknown set of RFCs with unknown acceptance and unknown browser support. Other than the above screen reader, I don't know how to get any feedback at all. For me, that makes it pretty opaque.

This video is awesome: youtube.com/watch?v=3f31oufqFSM

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!

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 role attribute

I 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 add aria attributes, expected keyboard functionality etc. (maybe role="alert" and role="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 dialog element 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 vw for 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-labelledby and 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.

That is the point and I completely agree, you want to create a custom select, be prepared to spend hours learning aria attributes that you are also very likely to get wrong. One example will use aria-haspopup and 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:

<div role="status" aria-live="polite" aria-atomic="true" aria-relevant="text">
     <!-- adding content here should be read by a screen reader -->
</div>

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-live region 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 of aria-relevant such 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-live region 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-live region each time to avoid this?

You have made me think that we need a "caniuse" for aria coupled 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?

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.

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!

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 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! ❤️

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.