DEV Community

loading...
Cover image for 🤷‍♂️ W1y d2s a11y h2e to be so b4y c9d a1d i10e? 👿

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

inhuofficial profile image InHuOfficial ・3 min read

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>
Enter fullscreen mode Exit fullscreen mode



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:

  1. Use semantic elements such as <nav>, <main> etc.
  2. Add alt attributes to images that describe the image in context.
  3. Add properly associated labels to forms
  4. Don't skip heading levels on a page.
  5. 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! ❤️

Discussion (64)

pic
Editor guide
Collapse
sargalias profile image
Spyros Argalias

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:

  • MDN
  • Google developer fundamentals

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?

Collapse
danm_c137 profile image
Daniel Morrison

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

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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!

Collapse
jeraldmayer profile image
urv.arts

Totally agree with you.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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!

Collapse
jackplug profile image
Stuart Homfray

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.

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? 😀

Thread Thread
inhuofficial profile image
InHuOfficial Author

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? 🤣

Thread Thread
jackplug profile image
Stuart Homfray

Absolutely! I'm sure it would be far better than my exasperated, "Do you WANT to make more fckin' money or what!?!" efforts 🤣

Thread Thread
inhuofficial profile image
InHuOfficial Author

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!

Collapse
sargalias profile image
Spyros Argalias

My pleasure. Those are just some thoughts for now. I'm interested to see how your work on this topic develops. Keep us posted :).

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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!

Collapse
joshcheek profile image
Josh Cheek

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.
Collapse
inhuofficial profile image
InHuOfficial Author

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!

Collapse
devlorenzo profile image
Collapse
inhuofficial profile image
InHuOfficial Author

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.

Thread Thread
theowlsden profile image
Shaquil Maria

We need a: Accessibility for dummies

Thread Thread
inhuofficial profile image
InHuOfficial Author

I am surprised that nobody has done that (I literally went to look for it when you said it 😋).

Agree 100%!!!

Thread Thread
inhuofficial profile image
InHuOfficial Author

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 😂

Thread Thread
theowlsden profile image
Shaquil Maria

Well that sounds like a hassle.

We gotta create our own version: XYZ for noobies😅😜

Collapse
jmau111 profile image
Julien Maury

In my case a11y helped me improve my skills. I'm a rich stack developer, but I originally come from the system/backend part. I had good knowledge of HTML, CSS and JS, but I needed to go far further.

Both the code and the look and feel are better now with accessibility (a11y) in mind. That's my point when I talk about a11y. You can do better apps for everyone, not just some polish for people with impairements.

However, while I agree with you that it's not so complicated, it is not that easy. I've seen and tested many "a11y enhancements" that are sadly worse for a11y.

Even the w3c validator makes suggestions that are sometimes not the right thing to do, so it's not just basic knowledge, and you need to keep it simple.

The biggest mistake could be to think a11y after making the app or in the very end of the process. That's is why people always say it's expensive.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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!

Collapse
jmau111 profile image
Julien Maury • Edited

if you are new you aren't going to understand how to implement that in Vue or Angular

For that, I consider it's part of the job. The developer must have learning skills, and that includes not reading tutorials and blog posts at face value.

The IT Business is often all about getting the job done, so you see copy/paste and stuff. We need better education and information, for sure, but as a developer, you have to teach yourself, and that is not so simple.

The good news is that it's a good investment.

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

It's a critical point. I see many people learning frameworks before the language itself. Big mistake. That's why you have online projects with way too much dependencies that loads kilobytes of code for almost nothing.

It's unlikely they care about a11y, not because they are bad persons, but because the priority is to get the job done by delivering the fuc*in feature.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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:

" We need better education and information, for sure, but as a developer, you have to teach yourself, and that is not so simple."

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 support role="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 d it should go to "duplicate", pressing d again 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! 🤣🤣

Thread Thread
jmau111 profile image
Julien Maury

You certainly have a point, I call it "the noise", and with blog posts and tutorials, we're part of it, somehow.

However, it's not all about the technical "truth". You can inspire and help people even if you're not accurate enough.

Besides, as long as there are people to post meaningful comments, rubbish information will go where it belongs, in the trash. I don't want people to be afraid of publishing, even if they need to level up.

In your example, how did the author react? Did he update his post? If that so, then no problem.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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.

Thread Thread
jmau111 profile image
Julien Maury

Yee comments can be tough sometimes, but most people do that in good faith. That does not mean you have to accept everything but you can learn a lot with a meaningful comment.

Perhaps you can use their contact form if you don't find any comment form ^^

Thread Thread
inhuofficial profile image
InHuOfficial Author

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!!!)

Collapse
ahferroin7 profile image
Austin S. Hemmelgarn • Edited

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:

  • Any time you are using an element for some purpose other than the one defined by the HTML standard, use the appropriate role attribute. 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.
  • Don’t interfere with zoom functionality, and don’t use a font size that’s a absolute number of pixels or scaled off of the viewport size (yes, I have actually seen sites that do that...). I don’t care if you think your layout only looks good at one scale, the user should not need to resort to OS-level functionality to be able to read your site (and your layout will be ugly from the perspective of such users anyway, because they will find a way to make things bigger or they will just not use your site). This one is not only easy to do (you quite simply don’t do something), it’s also a major issue even for people who do not technically have accessibility problems by most standard definitions.
Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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.

Collapse
ahferroin7 profile image
Austin S. Hemmelgarn

For the role attribute 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 dialog element, needing a polyfill just for support on major browsers (Safari completely lacks support, Firefox requires running the nightly or manually enabling the element in about: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 using role="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.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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 role attribute 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 role adds any benefit over its native HTML5 version.

Now with that being said I do agree with you on dialog but as I said, you then have the problem of needing to know aria-modal="true", aria-labelledby, add keyboard functionality, focus management, aria-haspopup on 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> requires role="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 of role="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" and role="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 add tabindex="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!

Thread Thread
ahferroin7 profile image
Austin S. Hemmelgarn

The things with dialogs though is that you don’t have to understand why you need to have aria-labeledby or 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, description comes to mind, as it’s dead simple to understand when to use it (if an element is pointed to by an aria-describedby attribute, it should have the description role).

A handful of cases are not reasonably usable without specific additional attributes, but the required additional attributes are pretty trivial to understand. progressbar is probably the best example of this, you just need an aria-valuemax set appropriately and an aria-valuenow that 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.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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.

Other than that, description comes to mind, as it’s dead simple to understand when to use it (if an element is pointed to by an aria-describedby attribute, it should have the description role).

Where did you read / learn that? I don't think role="description" is a real role?

Are you meaning aria-roledescription which is for custom elements?

aria-describedby is 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!

Collapse
danm_c137 profile image
Daniel Morrison • Edited

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.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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>
Enter fullscreen mode Exit fullscreen mode

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?

Collapse
danm_c137 profile image
Daniel Morrison

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.

Thread Thread
inhuofficial profile image
InHuOfficial Author • Edited

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-live region 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!)

Thread Thread
danm_c137 profile image
Daniel Morrison

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?

Thread Thread
inhuofficial profile image
InHuOfficial Author • Edited

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!

Collapse
aminnairi profile image
Amin

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?

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 alt on my img tags 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.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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.

Collapse
aminnairi profile image
Amin

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?

Thread Thread
inhuofficial profile image
InHuOfficial Author

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.

Collapse
theowlsden profile image
Shaquil Maria

Oh and what do you think about converting the tag a11y to accessibility and making them synonyms on dev.to?

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.

That is it! If you somehow manage to do those 5 items your site / web app / app will be 90% accessible.

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:

Collapse
inhuofficial profile image
InHuOfficial Author

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!

Collapse
theowlsden profile image
Shaquil Maria

Aight then!

If one more person agrees on the "a11y" thing then I will start harrassing the dev team to get it sorted

Just do it!🤣🤣🤣

Collapse
riyanagueco profile image
Riri

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.)

Collapse
inhuofficial profile image
InHuOfficial Author

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!)

Collapse
riyanagueco profile image
Riri

Thank you so much! 🙏 This will help me tons. I rely a lot on Chrome Lighthouse, didn't know NVDA and Accessibility Insights existed.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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!

Collapse
simbiosis profile image
SIMBIOSIS • Edited

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.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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.

Collapse
leicorre profile image
LeiCorre

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.

Collapse
inhuofficial profile image
InHuOfficial Author • Edited

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?

Collapse
leicorre profile image
LeiCorre • Edited

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.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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

Thread Thread
leicorre profile image
LeiCorre

Thank you for being so willing to address this area!

If you create a course, I would definitely be interested in learning from it.

Thread Thread
inhuofficial profile image
InHuOfficial Author

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

Collapse
devlorenzo profile image
Collapse
devlorenzo profile image
DevLorenzo

What do you think?

Collapse
inhuofficial profile image
InHuOfficial Author

Made me go towards “complicated” rather than accessible. Thanks I choose a better cover image and the inspiration was perfect!

Thread Thread
devlorenzo profile image
DevLorenzo

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!

Thread Thread
inhuofficial profile image
InHuOfficial Author

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!

Collapse
inhuofficial profile image
InHuOfficial Author

I like that actually! Thanks!