A11y DX: Developer Experience while abiding to accessibility

4 min readFeb 12, 2020

2020 is the last year for us in Norway to fix all of our web applications accessibility issues before Digitaliseringsdirektoratet will start their crack down 🚓 on all, not just new, web applications in 2021.

Will you see the money 💸 go out the window or will they be so hard on you (in Norwegian)?

There are no prerequisites to reading this article, but it is a good idea to have some basic knowledge of web accessibility. Please read my previous articles on the topic A11y 101: Grunderna i universell utformning (in Swedish) and A11y 2.1: Fortsättning i universell utformning (in Swedish).

As a developer you need to think 💭 when you write code. Follow standards, best practices and write semantic html — screen readers need to be able to parse and interpret the html just as any browser. But screen readers are less forgiving than the major browsers and more prone not to follow the standards.

Screen readers often feels as immature as the browsers of the early 21st century

In addition you need to make sure clickable elements are focusable, convey audio and visual information with text, use WAI-ARIA in the correct way and much more. All this can be hard to keep track of while you try to get a feature ready to be shipped. In the end you need to validate and test that what you have done is correct and works as expected.

Tooling 🧰

But manual labor is hard and boring! Fortunately there are ️tooling 🛠 — so robots 🤖 can suffer for us. They are less likely to fail on tedious tasks.

Devtools

Audit your application live in the browser Devtools with Vue Axe Devtools or React Axe Devtools.

if(process.env.NODE_ENV !== 'production') {
  const VueAxe = require('vue-axe')
  Vue.use(VueAxe, {
    clearConsoleOnUpdate: false
  })
}

Linting

Avoid coding mistakes by linting with accessibility rules with Vue ESLint, JSX ESLint, JSX TSLint or Angular Codelyzer.

"eslintConfig": {
  "extends": [
    "plugin:vue-a11y/recommended",
  ],
}

Unit testing

Add accessibility validation to your unit tests with Jest Axe.

import {axe, toHaveNoViolations} from 'jest-axe'
expect.extend(toHaveNoViolations)
it('element has no axe violations', async () => {
  const wrapper = shallowMount(Component, {})
  const results = await axe(wrapper.element)
  expect(results).toHaveNoViolations()
})

End-to-End testing

Add accessibility testing to your applications End-to-End tests, to verify your components are still accessible after being put together to a web application, with axe-core.

it('home route has no violations', () => {
  cy.visit('/')
  cy.injectAxe()
  cy.checkA11y()
})

Read more about setting up and starting with End-to-End testing, in my articles Skippa manuell testning med Cypress (in Swedish) and Skippa manuell testning med Puppeteer (in Swedish) — this can save 💾 you from the complete and utter boredom of manual testing.

CI/CD

Make sure to hook up all your accessibility tests with your CI/CD pipeline. If your have not written any tests or your test suite does not cover your whole application you can apply tools like Pa11y to traverse your application from a list or a sitemap.

pa11y-ci --sitemap http://test.yourdomain.com/sitemap.xml

Team work

As developers we are used to having requirements put upon us: from product owners to deliver features; from designers to implement designs; from testers to implement without bugs 🐞. Now it is time for us to put the flame 🔥 on everyone else on the team. Because software development is not for lone wolves 🐺, it is a team sport, and everyone needs to contribute to the best of their abilities.

Product Owners 🤵

Who will have to work overtime on Christmas Eve due to the findings in the supervision 👮?! It will have to be someone who can fix the problem and push to production — that is you 🦹‍♂️ alright — it sure as hell 👿 is not them. Maybe they will stand behind you while you are at it but there is probably all whip and no carrot 🥕! Time to require that work on accessibility is prioritized from the get go.

Designers 👩‍🎨

In the beginning there were, hopefully, image sketches. Nowadays we are used to pretty fancy responsive design sketches in tools where you can see real style values — values often structured and limited by design patterns. But there are still only sketches for visual design. What about requiring sketches for non-visual design? In what order are things to be presented, what are those icons going to say if you can not see them?

Testers 🕵️

Try again, only right this time. -Tester

Have you ever gotten a ticket 🎫 back from a tester? Maybe it could serve them right to have their tickets moved back too and start to require testing to be done with keyboard navigation, screen readers, and so on …

Time to pop the champagne 🍾.
Good luck, I know you 👨‍💻 can do this!