On accessibility support

1

Hey friends, I initially wanted to post this as a GitHub issue, but it came out a bit too casual, so uhm, long post ahead.

I have seen enough accessibility issues during the week that my eyes are starting to bleed, and I thought I should share something.

Basically, we are building some UI components at work, and due to the complexity of the components, we decided to rely on a third-party library rather than building them from scratch. We found a library that almost matches our needs out of the box, but the lack of customization options blocks us from fulfilling our requirements. To beat the deadline, we had no choice but to fork the repo and adjust it ourselves. We found a few accessibility issues in the library during the research stage, but only when we started diving deep into the implementation, we were surprised at the actual amount of the issues, some of those are critical and will fail any basic audit.

They are mostly strange behavior in keyboard navigation pattern (let buttons do their job, don’t tabindex=-1 them), and the incorrect usage of HTML elements (<a> is purely for links, not for actions). Anyway, we have been addressing these on our side to comply with our a11y requirements.

The week got worse for me as I stumbled upon this Ant Design issue. Please go ahead and read that first, I’ll wait. I recommend reading through the main issue the OP linked as well, but maybe after my post :stuck_out_tongue:

Now, this got a bit personal to me, as the author, @zersiax, is the one that brought my attention to the importance of a11y (but he doesn’t know that). I think some of you remember, Florian helped freeCodeCamp with some a11y guides back then as well as reporting a11y issues he found; and I helped fix one or two of those.

My post here by no mean is to call out Ant Design. I have seen them being very proactive with a11y issues reported, but this particular one is huge, both in the severity and in what needs to be changed. I can imagine it will take a while for them to address this. But that’s not what I wanted to point out. What I wanted to say is, issues like this happen because a11y support is often missed in the technical planning phase, and by the time the implementation is complete, tech debt might already be built up that makes things hard to change, or the implementation approach doesn’t leave much room for modifications. This is something I am guilty of as well.

I would like to bring this up now so we can learn from that and keep a11y support a must-have criteria in our future updates. I for sure will try to keep the component library in check as best as I can, but there are a lot of other items I can do to help FCC with this.

I will occasionally spot check all FCC platforms, and I encourage everyone to do the same. I think I will report issues I find, and instead of fixing them myself, I will ask for contributions from others, especially first-time contributors, who are likely campers. This is a great way to get exposure to working with a11y support and make significant impact.

I do plan to write up a guide for the component library, which will include how to write meaningful unit tests. I can talk a lot more about this topic, but to keep things simple for now, going forward, we should try to use the React Testing Library’s ByRole query in our tests, rather than looking for class name or element name (see the priority list here). There is also a great article for unit tests best practices by Kent C. Dodds.

The efforts should not stop here at FCC. I would ask everyone to help audit and fix a11y issues in other open source libraries as well, those that you have been using a lot and are more familiar with, or help Ant Design with the issue above.

As for the library I mentioned earlier, the decision to fork it leaves a bad taste in my mouth given how much I love the open source community (and what’s worse is that I am the one who made the decision). Our team has a plan to contribute the a11y fixes back to the library once our project is complete, so I think I will feel better then.

Hookay, this post is super long now. If you excuse me, I need to head to /r/aww for eyebleach.

Have a great weekend!

4 Likes
2

+1, Huyen. You’re right when you say that usually accessibility never comes to a lot of projects because work eventually piles up, and that is to be expected. I am in favour of having a11y as a necessity for our future upgrades.

P.S.: I haven’t much experience with a11y and auditing websites for that, but would love to hear more about the topic from you :slight_smile:

1 Like
3

I would not feel bad about this. This is exactly how open source works. You fix things and then contribute those fixes back to the project.

As for accessibility in general, you are unfortunately correct, historically it has been an afterthought, if that, and more often than not ignored. But I think this is gradually changing, and maybe faster than we think. I’m currently in the process of studying for IAAP Web Accessibility Specialist certification. I’ve pretty much immersed myself in the a11y dev community and it is growing rapidly. My gut tells me that accessibility is going to explode here in the coming years and there will be a big demand for developers that understand a11y issues. I hope I’m not wrong.

2 Likes
4

The reason I created that issue over at Ant Design is because by their
own admission, a lot of projects use their components. Components that
are, unfortunately, quite broken, which makes the tools that use these
components broken by default without the developer of the tool being
aware of it if it isn’t pointed out.
This is a severe issue and reminds one of FreeCodeCamp in the
CodeMirror days when I first stepped in. FCC wanted to do this right,
but due to reliance on a 3rd-party package, that cornerstone of
standing on the shoulders of giants that signifies programming these
days, they actually couldn’t, until the tool in question got updated,
or replaced.
As you can see, the only response to my issue was a comment that
they’d be happy to merge my PR if I were to fix it. Obviously that is
how FOSS tends to work, but also, I shouldn’t be the person who goes
in and fixes every accessibility issue I encounter. Unfortunately
though, this response is far from uncommon. One has to balance
delegating the fix to the user and making the bug the user’s problem,
and I think that here, that balance was tilted in the wrong direction
a tad too far, which now means several tools will be inaccessible by
default.
I like the approach for FCC that is detailed here, and feel free to
poke me with questions if they ever coem up :slight_smile:

1 Like
5

Personally, I see no problem with an open source project stating that you are welcome to open a pull request to fix an issue if you get to it before they have the bandwidth to do so, especially since it appears that you are recommending expansive edits to core code.

6

Heh I’m not an expert myself :sweat_smile:

IMHO, the best way to learn about a11y is to build web components from scratch. Having to work with HTML elements and learn about what they are for, what they mean, how screen readers would identify them, etc. help me understand the web a lot better.

I’m not sure if you already know, but FCC is going to have its own component library (tracked in this issue), which will be mostly built from scratch and allows us to get things right from ground up. There is a couple of setup work left that I need to do before calling for contributions, but let me know if you’re interested.

7

You’re right, Bruce. I got into web accessibility by choice when I was browsing for some issue to contribute, but it got serious when I have to learn more intensively on the job, as a11y compliance is in our contract with the customers.

I do hope that a11y becomes a legal requirement in more countries, and that a11y is in JD as a requirement rather than a good-to-have skill.

8

It’s been a while since we’ve seen zersiax — their last post was 4 years ago.

@zersiax I think I accidentally summoned you here :stuck_out_tongue: So great to see you again!

I hear you. It was painful to read that issue description and to imagine how it has been impacting the users. I think the issue has been there but got unnoticed until you reported, so thanks for bringing awareness.

Anyway, speaking of CodeMirror, it is long gone now. Monaco editor is what FCC is currently using. It is the edit that powers VSCode, so a11y is also covered.

There will be a lot of new updates from FCC that we would love to pick a11y experts’ brains. One of those projects is a new component library, which I am working on. I’ll be sure to bug you for feedback.

9

Hah! Good to be back.
I’ve kept an eye on FCC over the years, really excited to see when the
project-based curriculum is going to be a thing :slight_smile:
I know about Monaco, and fortunately CodeMirror appears to be trying
to clean up their act as well in the new beta …which has been a beta
for a pretty long time, no idea when that will become the new stable
version :slight_smile:
But yeah, feel free to poke me with questions. I’m here, just not all
that active on the forum. Wow, 4 years ago huh? :stuck_out_tongue:

10

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.