🤷♂️ W1y d2s a11y h2e to be so b4y c9d a1d i10e? 👿
source link: https://dev.to/inhuofficial/w1y-d2s-a11y-h2e-to-be-so-b4y-c9d-a1d-i10e-38no
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
🤷♂️ W1y d2s a11y h2e to be so b4y c9d a1d i10e? 👿
May 1
・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>
It shouldn't have taken me 1500 words to answer that question, the answer should be simple.
No.
(ironically I landed on "technically yes" which is unreal, read it and see if you agree!)
The basics are easy but we over complicate things!
I mean here is all you need to know to solve 90% of accessibility issues I see every day:
- Use semantic elements such as
<nav>,<main>etc. - Add
altattributes to images that describe the image in context. - Add properly associated labels to forms
- Don't skip heading levels on a page.
- Don't use poor contrasting colours - use a contrast checker
That is it! If you somehow manage to do those 5 items your site / web app / app will be 90% accessible.
If you are new to development then learning those 5 things will make you a better developer (in my eyes) than many "senior" devs who still use <div> soup to structure their documents!
And the best thing? You can learn all 5 of them in less than a day!
I mean don't get me wrong, the final 10% does require a lot more knowledge, but that is all, knowledge. If the documentation was easier I am sure more people would look it up and implement it.
Do you think we can do better?
So what do you think? Confused by WAI-ARIA, WCAG, ATAG, VPAT etc? I know that even now I can really get bogged down in everything, I hate to think what people just starting out learning about accessibility feel!
I am hoping WCAG 3.0 (formerly WCAG project Silver) will fix a lot of these issues but that is over 8 years away before it becomes the standard according to current plans!
"WCAG 3 is not expected to be a completed W3C standard for a few more years. WCAG 3 will not supersede WCAG 2, and WCAG 2 will not be deprecated, for at least several years after WCAG 3 is finalized." - source WCAG 3.0 Introduction on W3
So in the mean time I suppose what I am asking is: what would you like to see / do you need that would make it easier for you to learn / implement accessibility?
Oh and what do you think about converting the tag a11y to accessibility and making them synonyms on dev.to?
I look forward to your thoughts and ideas! Any good ones I will turn into a post / series!
/end rant 😋
p.s. I really struggled to find a meaningful cover image for this article, anyone seen a better one I can use for inspiration that isn't using the stereotypical "person in wheelchair" to denote accessibility??
Edit: thanks to @devlorenzo for finding an image that helped me pick a better one! ❤️
Discussion (51)
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:
- 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?
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!
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
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
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
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'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!
CollapseExpand
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!
CollapseExpand
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
We need a: Accessibility for dummies
Thread
Thread
I am surprised that nobody has done that (I literally went to look for it when you said it 😋).
Agree 100%!!!
Thread
Thread
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
Well that sounds like a hassle.
We gotta create our own version: XYZ for noobies😅😜
CollapseExpand
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.
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!
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
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
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
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
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
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!!!)
CollapseExpand
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.
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?
Thread
Thread
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.
CollapseExpand
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 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?
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
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
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
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!
CollapseExpand
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
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. - 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.
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.
CollapseExpand
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:
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!
If one more person agrees on the "a11y" thing then I will start harrassing the dev team to get it sorted
Just do it!🤣🤣🤣
CollapseExpand
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.
Thread
Thread
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
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
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! ❤
CollapseExpand
CollapseExpand
CollapseExpand
Made me go towards “complicated” rather than accessible. Thanks I choose a better cover image and the inspiration was perfect!
Thread
Thread
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
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!
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK