Skip to content

Accessible Components: Test Driven ApproachJump to section titled Accessible Components: Test Driven Approach

The web is undoubtedly the most vital resource today. Modern websites are built-in small building blocks; components. Practices from test-driven software development have employed to automate the correctness of these building blocks.

The internet should be accessible to all. It is essential to provide equal access and opportunity to people with disabilities.

You can find many tools to check accessibility on web pages. But, in my opinion, when you’re testing web pages in a modern application, you’re very late. Accessibility testing should be employed at the lowest level; you should create accessible components.

Unit Testing AccessibilityJump to section titled Unit Testing Accessibility

Let’s simple component which renders following HTML:

<button role="datepicker">test</button>

The <button> element has an invalid role value. We’ll validate generated HTML with a11y utility. ARIA AX_ARIA_01 rule would fail with the following message:

Elements with ARIA roles must use a valid, non-abstract ARIA role.

<template>
  <button class="button" role="datepicker">
    <slot />
  </button>
</template>

<script>
export default {
  name: 'MyButton',
}
</script>
import it from 'ava'
import pify from 'pify'
import _a11y from 'a11y'
import _fs from 'fs'
import { mount } from 'vue-test-utils'
import { createRenderer } from 'vue-server-renderer'

import TargetComponent from '../src/Button.vue'

const renderer = createRenderer()
const a11y = pify(_a11y)
const fs = pify(_fs)

it('should be accessible', async (t) => {
  const w = mount({
    template: `<TargetComponent/>`,
    methods: { doSomething() {} },
    components: { TargetComponent },
  })
  const html = await renderer.renderToString(w.vm)
  const filename = '/tmp/a11y-test-source.html'

  await fs.writeFile(
    filename,
    `
  <!doctype html>
  <html lang=en>
    <head>
      <title>Test Component</title>
    </head>
    <body>
      ${html}
    </body>
  </html>
  `,
  )

  const reports = await a11y(filename)

  reports.audit.forEach((report) => {
    t.true(report.result !== 'FAIL', `[${report.severity.toUpperCase()}] ${report.heading}`)
  })
})

The above example demonstrates static checks HTML for accessibility. Next, I would be exploring techniques to test accessibility for all four types of disabilities — visual, auditory, motor, and cognitive. The a11y project has curated a list of rules as web accessibility checklist, an automated tool to run these rules would be next step in my accessibility exploration.