Looking back at the past year (and a half) of accessibility work.

This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Sarah

Originally published on my blog.

It's the end of the year, which means time to look back at what has been and write a year in review blog post about it. Because it's been silent on my blog for a while, I decided to combine it with another post that's long overdue: a recap of my first year (and a half) of freelancing.

In 2021, after roughly 7 years of working in tech, I decided to quit my job as a senior front-end developer in favour of starting my own company and work as an independent consultant. It was a scary decision, but has absolutely proven to be the right one.

Work

While having to find your own clients and plan your own work is one of the things that makes freelancing scary, it also has allowed me to find projects that are much more in line with my skills and interests.

I've gotten to work on some really interesting projects the past year and a half, including the following:

• Contributed with accessibility reviews and guidelines to the WHO Data Design Language, for which I was part of Truth & Beauty's team.
• Accessibility and front-end consulting for a long-term and repeat client: I assist with fixing accessibility bugs, implement and review new features, and help build internal accessibility documentation and knowledge.
• Performed accessibility reviews for different products and websites. For example, I audited on all of FINN.no's data visualizations, and provided the designers and developers with guidance, documentation and tools to implement the fixes and make improvements. I also reviewed all of the State of JS and State of CSS graphs, based on Chartability.
• Accessibility talks and training: including at SHOW conference, FINN.no UX Design Evenings, Little Miss Robot's Product Design Meetup (hosted @ my old university, almost felt like being back in school), and more. I also started doing internal accessibility training, office hours, and Q&As with some clients.
• Wrote an essay on screen reader accessible data visualizations as part of The Urban Institute's Do No Harm Guide on Centering Accessibility In Data Visualizations. The report has 9 different essays by different folks in the dataviz accessibility field.

I also implemented a whole lot of new features across projects. Most of those were written in React and TypeScript, but I also had a couple of fun projects that combined Eleventy/Sanity as well.

Accessibility Observations

1. Many people actually do want to prioritize accessibility.

Throughout my career (almost 10 years at the time of writing this post) I've frequently come across people who just refused to care about accessibility. My main experience was always having to advocate hard for it.

I remember leaving a comment about changing a

(with a clickhandler and styled like a button) to an actual on a PR and the developer refusing to address it because they felt accessibility wasn't important enough. Or another time having to justify myself to a manager for spending time on making a color scheme more accessible. The conversation with him took longer than the actual work.

However, the past year and a half I've mainly come across the opposite: people who are looking to improve their accessibility skills, who ask a lot of questions, and who are excited to deliver an accessible quality product from the start, rather than moving fast and breaking things.

2. The tech industry faces a lot of accessibility blockers.

The enthusiasm for accessibility work doesn't necessarily translate into accessible products, though. One of the most asked questions I get after talks is still some variation of "how do I convince my boss to let me work on accessibility?" (and a blog post about this is coming soon™).

But when talking to project managers, I also often hear similar struggles: they're trying to plan around a deadline someone else has set or work within a budget they didn't decide on.

Amongst the type of companies that contact me are also design agencies and consultancies, where the time and money the team can spend on accessibility work also depends on the budget they received from their clients.

On top of that, I feel like there are a lot of accessibility knowledge gaps in the industry. Bootcamps and college degrees don't always touch upon the topic, so not everyone enters the workforce knowing about it. Learning new skills also takes time and energy, and if you want to follow a course or book, also money. Doing this after work and out of own pocket isn't achievable for everyone (and shouldn't be the expectation), but how much learning can be done on the job really depends on the company.

Long story short: there are a a lot of things that may block accessibility efforts, even if we have good intentions or come prepared. We can't necessarily control our circumstances, but we can control how we prepare for them and respond to them.

3. Accessibility bugs are more often caused by broken processes than broken code.

Yes, a lot of accessibility issues are caused by how the code is written (or how the product is designed), but the fact that inaccessible features make it into a live version that's released to users, that's typically an issue with our processes.

Most people do some sort of quality control of their products before pushing them out. Depending on the size of the company or poject that could be anything from a designer taking a quick look at what the developer built, or a detailed process involving multiple code reviews, and automatic and manual tests.

Some of the most common issues I come across are:

• Missing or unclear alt text. Missing alt text can be picked up by linters, unit tests, and automatic testing tools such as Axe and Lighthouse. It can also be viewed in the browser through the inspector (developer tools), or by using a screen reader on the page.
• Divs used as buttons, without the appropriate roles, labels, or keyboard controls. Most issues related to semantics will be flagged by linters and automatic testing tools, but this is also something that can be flagged in code reviews. The behavior can be tested manually by using the keyboard in the browser.
• Elements disappearing/blocking the view when zooming in. This can be tested during and after development by zooming in to the browser when doing manual tests. Designers can also document how the page should behave on zoom/resize.
• Lack of color contrast. This can be tested by design tool plugins (eg. Able, Stark), automated testing tools, and web-based color contrast checkers.

If a lot of those bugs are created while building, it can be an indication the team needs accessibility training (or hire more accessibility-focused engineers/designers). But if they make it into production, in my experience it usually means one or more of those things:

1. There wasn't enough testing/quality assurance in general.
2. The testing and quality assurance didn't include accessibility.
3. Accessibility issues were flagged, but fixes deprioritized.
4. Fixes for the bugs were prioritized, but no one's available to fix them.
5. There's no way to discover or track accessibility issues.

4. Progress over perfection: small improvements can go a long way.

It's not always possible to fix all accessibility issues a website has at once, and we may not alwyas find the best solution on the first or second try. If we try to fix everything in one go, we risk ending up fixing nothing at all.

If there's a limited accessibility budget, it can be more productive to do a high-level review of the product and help the team understand how to fix and prevent the issues, rather than holding out from doing anything until someone wants to set resources aside for a full in-depth WCAG audit (which may never happen).

Some of the "smallest" accessibility issues to solve can also be some of the largest blockers. I've come across menus where each menu item was labelled "image" and none of the pages had unique titles. From a technical point of view, that's a small mistake with an easy fix (add a text label to the icons). But for screen reader users this made the app unusable.

The more of those seemingly small issues get fixed, the deeper the conversation around accessibility can be, and the more useful user feedback can be collected.

Looking into 2023.

I'm mainly hoping to continue what I started in 2023: do a good mix of projects, with a focus on accessibility. That means front-end/accessibility consulting work, accessibility reviews, documentation, and training. I especially want to streamline and strengthen my auditing and training offering.

I have also set time aside for building accessibility tools for my company to start using (stay tuned 👀), and am also planning on writing and building in the open a whole lot more.

For example, I'm currently building a customizable links page:

• Preview: links.fossheim.io
• GitHub repo

I genuinely had a good year in 2022. I got to spend a lot of time with my wife and dogs, recovered from burnout and CPTSD, and had a fully-booked year of interesting clients. I hope I'm not jinxing it by writing this post, but I wouldn't mind another year like this ❤️

Happy New Year!

This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Sarah