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.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Recently I was refactoring some frontend code and discovered some attributes on a custom progress bar one of our designers had made. I had no idea what they were, so I googled them and discovered were for accessibility. They allowed the tools to understand that it was a progress bar and how much progress had been made.
After reading about it a bit, I thought we could simplify our code and potentially have better accessability results by removing a bunch of our calculations that converted it into 0-100% and passing the values directly through.
I must have searched for half an hour trying to find something that would interact with the resulting HTML. I really couldn't figure out how to actually interact with those values. Finally the lady I was pairing with figured out how to configure the computer-to read the screen (this was computer-wide, it was even reading my terminal to me). So we turned that on, watched a tutorial to figure out how to interact with it, figured out some configuration to make it less annoying, and finally over an hour later, got it to focus on the progress bar and listened to the old and new descriptions to confirm that yes, the new values were an improvement.
Point of this story is that, despite some of the early commenters proposing that devs don't care, it's less about that, and more that it seems somewhat opaque and is extremely inconvenient. I definitely almost threw my hands up several times and said "whatever, it's good enough the way it is".
I don't think I have any amazing insights, but some aspects of my perspective may have value, so I'll list them out. Sorry if others have already mentioned these, I read about 20% of the replies, but there were a lot of them. And sorry if my issues are obvious to someone in the know, I'm not in the know, so just describing what it's like from where I'm at.
The story you told is mirrored in a lot of comments and when I think back, my own frustrations trying to learn the subject.
The thing is that point of "I almost threw my hands up several times" - that is where most developers then see accessibility as difficult, time consuming and think "there can't be that many people using a screen reader so why should I bother.
I do not think there is a single developer who has gone "I don't care", I think the problem is "I care, but I don't know why I should care and doing something about it is just not feasible within current time constraints".
I have been guided by the comments so far to suggest we have a library of "skeletons" for components. With brief explanations of each property and why they must be there and what options they take. Similar to API documentation (you know, it tells you 80% of the story but there are always some "gotchyas!" 🤣)
Your two points are interesting at the end, the different way of learning (which to be fair is much more towards the way I learn - let me play with it, let me break it, let me put it back together, just guide me as I do it) is one I need to consider on how to get the balance between "impossible to set up" (i.e. having a live sandbox that checks your work....too complex) and "not useful" (i.e. just some static text with "do this" written next to it).
You are certainly correct on the opaqueness....I mean that is where my rant comes from in that I answer the same questions that people could easily understand, but it is so difficult to get the answers they are after as the info is either buried in the thousands of pages of WCAG or on some random blog that you may or may not be able to trust!
Thank you for all of the points, I will go away and process them.
p.s. I have given a couple of comments here that point to tools that are useful to help you find and learn about accessibility issues. Have a quick look through for links you want "Axe" and "Accessibility Insights" or just look them up on the Chrome plugin store. As for screen readers - on Mac you have "VoiceOver" built in and on PC you can download "NVDA" for free. It takes maybe an hour to learn the controls to a level where you can use them....give one of them a go on your site - that is the best test and the biggest "eye opener" ever!