Not accessible - React told me off! by Prae Songprasit

Wireframe of a website, with icon and navigation at the top, hero image, then text content

I started my career in web as a junior designer.

Within the first month, I realised that I didn't enjoy designing, but I sure enjoyed coding up people's designs with HTML and CSS. So I've been a front-end person ever since.

I love creating responsive designs and improving usability of designs through code. I was mainly working on large information heavy sites for many years, so using HTML, CSS and a little touch of JavaScript was enough.

That is how I've managed to avoid learning to code in modern JavaScript frameworks like React for most of my career.

Majority of my previous projects focused on templating informative pages (like tourism websites), my testing knowledge only extends to manual multi-device regression testing, and network throttling in the browser to check site performance.

Since my code is usually concerned with visuals, in a fixed budget fast-pace agency environment, I didn't know, or needed to know how to write tests for my front-end code.

Why test code?

Reduce errors on complex interactive sites

Simplified UI of 4 to-do list states, empty, with an item added, done, and archived

Think of to-do apps. It looks simple, a list title with lists of items.

But there's a lot more to it than you think. I have to allow users to add whatever text they want as a dismissable list item.

There's logic to control when a list item should be displayed, when it should appear in the 'done' or an 'archived' state, and when it should be permanently deleted.

With so much microinteraction and power in the hands of my users, a lot more code could go wrong here.

If I didn't code the list logic properly, archiving a list item could permanently delete that item by accident.

And what happens, if someone uses a special character?

Many JavaScript frameworks like React are designed, so that this sort of complex logic can be done in the browser, without forcing the users to refresh their browser.

In the early days of the web, most logic that deals with content happens in the server, not the browser.

So back-end developers who often use traditional imperative programming languages are expected to write tests, to ensure that the logic works as expected under different scenarios. It's good code quality control and development practice.

But writing logical tests for front-end web interfaces is a much newer concept, especially for me.

The first unit testing tool I've ever used was the React version of the open source library, called the 'Testing Library'.

React
Testing Library

Enforce user centric tests

						<Button
	label="Add a new fish"
	onClick="this.showFishInput"
/>

<Input
	aria-label="Fish name"
	class="fishInput"
/>

fireEvent.showFishInput()

expect(<Input class="fishInput"/>) to render 🤯

For example, I was tasked to write tests for a button that would show an input field.

On the screen, you can see React Button markup, with label 'add a new fish' and an onClick handler,
which will run showFishInput that renders

Below the button, is input code it suppose to render.

The input field was marked up with aria-label 'Fish name', and class called 'fishInput'.

A note that in this example, the function's syntax isn't entirely accurate,
and Input field doesn't have a visible label... and used aria-label.... I've only done that to simplified the slide.

Please get correct syntax from docs,
and add a visible label then link it to input using for and ID attribute instead!!

Anyway...

In the past, the back-end style of writing tests, would focus on testing the function and implementation itself. In this case, the test would:

Fire event called showFishInput, and expect an input with class called 'fishInput' to render

The problem I have with this, is that it only tests if the input field with a class name "fishInput" appears on the page when that code is executed. The test doesn't care if there's an accessible name called "Fish name" attached to that newly rendered input field.

That's not how users think about this interface.

Users don't care about a classname? CSS classes are not visible to users on the page; their screen reader won't read it, and voice dictation tools can't find an element using CSS class.

This, is how you'd write it in React Testing Library

						<Button
	label="Add a new fish"
	onClick="this.showFishInput"
/>

<Input
	aria-label="Fish name"
	class="fishInput"
/>

userEvent.click(screen.getByText('Add a new fish'));

expect(
	screen.getByRole('input', { name: 'Fish name' })
).toBeInTheDocument(); ❤️

userEvent "Add a new fish" was clicked.

The test expect an input field with an accessible name called "Fish name" to appear.

React Testing Library is accessibility-first like that.

It encourages engineers to write tests that queries accessible names and DOM roles, rather than arbitrary IDs and Classes that users don't care about.

In this example, I used getByRole to find the input field.

But you can query or find things in the DOM by other useful static things like ByTitle, ByAltText, ByDisplayValue, even interactive states like pressed, checked, selected.

This is fantastic, because if the test cannot access those values, then something is seriously inaccessible about your code.

I once spotted an issue, where a hidden attribute accidentally remained attached to a component that should be displaying.

The query told me there's a problem because it couldn't find this hidden text.

Simplified UI of 2 identical looking interactive elements, which could be a select box or a dropdown. One element's accessible name is Fish habitat, fresh water. Another element's name is Fish habitat.

What prompted me to write this talk, was when React Testing Library once helped me spotted that we used the wrong component from our design system.

On the screen, I've put up UI of 2 identical looking interactive elements,
it could be a select box or a dropdown.

My team needed a dropdown UI, so we quickly picked up one that seems easiest to implement.

In this example, the dropdown UI had a visible label called fish habitat, that shouldn't change.

We wrote the test to select an option to display information related to that habitat. In this case, 'fresh water'

We found out that the dropdown's accesible name after we selected 'fresh water', was 'fish habitat, fresh water'

We were very confused. Why is did the accessible name changed when something was selected?

We tested with a screen reader, and it announced the same thing!

Simplified UI of 2 identical looking interactive elements. The first element, which is a select input, has a visible label called Fish Habitat, showing that Fresh water option was selected. Its accessible name is Fish habitat, Fresh water. Another element is a custom dropdown menu with both visible and accessible name of Fish habitat.

Turns out, the problem was that we used a select component, instead of a dropdown menu.

Select is a type of input field. It was originally designed for form submissions.

Usually, a select input field would have a visible label.

Once an option was selected, the screen reader would read both label and value. Just like any other input fields that was properly related to a label.

My team saw that the design system component came with an option to hide visible label. The design didn't have one above the trigger, so we enabled that

Our design sytem team realised that a select input will only annouce the value of 'fresh water' without any context to screen reader users.

So they tried to be helpful and sets aria-label for the select input as label, and value. Hence the Fresh habitat and fresh water annoucement

We should have used the dropdown menu component,
that was designed to be just a menu of repeatable activities people could do on a page, hence no need to annouce what's selected

The dropdown accessible name never change.

Thanks to React Testing Library, it nudge us to reimplement the feature with the right component.

What about React?

Improved docs,
development assistance, & bundling

I talked quite a bit about the React version of Testing Library.

But as the name suggests, it's a library. Something designed to be used in conjunction with a framework. It's not React itself.

So what does React itself actually do to help nudge engineers to write more accessible code?

It ries to improve its docs, and recommend more development assistance, & bundle those recommendations in their starter kit.

With documentation,

React understand that beginners copy and paste code quite blindly when learning.

So their copy-paste examples all throughout their docs are getting better, and more accessibility conscious all the time.

That is of course, human intervention. Requires reading. What about machine intervention?

Well, is to recommend basic development assistance

						<img src="fishyImage.png"/>

(image-alt):
Ensures <img> elements have alternate text
or a role of none or presentation


<button tabindex="2">
	Add a new fish
</button>

(tabindex):
Ensures tabindex attribute values
are not greater than 0

Everyone makes mistakes. Whenever possible, let tools instead of people tell them off.

There are some basic accessibility linting tools like axe-linter or eslint-plugin-jsx-a11y.

It would highlight an HTML attribute that isn't right, or is missing for a specific type of element with a red squiggly line like when you made a typo, and would show warnings in the console.

The example on the screen, shows linting messages for image and a button called Add a new fish with tabindex 2.

The linting message said:

that the image needed an alternative text or a role of non or presentation

For the button, it said that tabindex value should be no greater than 0.

This is a great way to remind engineers basic things while they're coding.

The last thing React did, was to recommend good practices in Create React App starter guide

Create React App

People can
ignore tests?!

Yes... but you can make it harder

Bake it in

TDD, prevent commits & stop deploys

But if your team does test driven development, where you write tests first, then write real code which would fix the test, then React Testing Library will slot right into your workflow

As for development assistance like linting… You can turn some linting tools off, like additional libraries or extensions attached to your code editor. And frustratingly, many engineers unfamiliar with front-end landscape do. So engineers could simply ignore many linting warnings.

You can put in the last resort, of making sure that people cannot deploy code without passing accessibility tests and or linters.

You can chain accessibility linter to the same test command you use before committing, pushing locally, and during build to deploy.

If the tests fail, then the engineers won't be able to push code or run a successful build and deploy that code to production.

Let the bots tell people off… rather than your team mates.

React told me off

...but not all the time

As you can see, React, React Testing Library, and other accessibility linting tools are trying to improve accessibility in several ways:

It tries to change the way you approach writing tests. To think more along the lines of what users do on the page, and querying accessible names or roles to check if something works as expected
It tries to embed basic accessibility as a part of the development process or deployment pipeline
It tries to nudge you to add important things like alt tags to images, and accessible names in links and buttons.

It will tell me off, if my element doesn't have an accessible name. But robots don't understand what the 'most usable' accessible name looks like.

If I wasn't an UX conscious engineer, I may have fixed the issue by putting a random text in as an element's accessible name and calling it the day.

Bots don't know UX

Good HTML & copy...
We need humans for that

People can't properly address low-hanging issues raised by tooling, without understanding why that was considered an issue.

They need to understand HTML, yes, but also how copy design fits into the whole experience.

Copy is a core part of good UX. It's crucial for assistive technologies.

And as of now, bots hasn't gotten smart enough, to be the judge of what a good copy looks like yet.

It can't tell if your tab order is all messed up either.

Another problem, is that new team members who weren't involved in the automated tests and linting tool setup,
may incorrectly assume that's it. You're accessible if all tests passed.

Team needs to create an embeded culture of making things accessible in all part of the process, from research, to design, to criteria writing, to testing to prevent that misunderstanding.

So yes, React could tell me off for writing some inaccessible code.

But we still have to rely on human coders, testers, and designers to figure out what makes sense for our UI.

Accessibility is a mindset,
not a standalone activity

@PraeSongprasit and @WebAccessClub