Making Websites Better through Accessibility
Tags: webdev, a11y
Published: 2020-02-17 17:59:46

---
title: Making Websites Better through Accessibility
published: true
date: 2017-07-23 22:42:00 UTC
tags: webdev,a11y,accessibility
canonical_url: https://nystudio107.com/blog/making-websites-accessible-americans-with-disabilities-act-ada
---

# Making Websites Better through Accessibility

### Mak­ing your web­site acces­si­ble isn’t just about legal com­pli­ance, it also means not turn­ing away cus­tomers. Because who wants to do that?

Andrew Welch / [nystudio107](https://nystudio107.com)

![Web Accessibility Ada](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x675_crop_center-center_82_line/web-accessibility-ada.jpg)

Mak­ing your web­site acces­si­ble means mak­ing it avail­able to the largest num­ber of peo­ple pos­si­ble. It’s already a Her­culean task to get peo­ple to your web­site to begin with, so we cer­tain­ly don’t want to turn a % of peo­ple away due to acces­si­bil­i­ty issues.

I find that many devel­op­ers don’t real­ly under­stand acces­si­bil­i­ty, or shuf­fle it off to the ​“it’d be nice” list on their tasks. With a lit­tle edu­ca­tion and prop­er tool­ing, it does­n’t have to be that way.

<aside>
                                I view web­site acces­si­bil­i­ty as cus­tomer acqui­si­tion, as well as build­ing an inclu­sive web­site that serves the most num­ber of peo­ple as possible
                            </aside>

In many coun­tries, web­site acces­si­bil­i­ty is also man­dat­ed by the law. In the USA, for instance, there is the [Amer­i­cans with Dis­abil­i­ties Act](https://www.ada.gov/) (ADA), which the DOJ has made clear extends to the Internet.

Com­pa­nies such as Tar­get (see [NFB V. Tar­get](https://www.w3.org/WAI/bcase/target-case-study)) and Net­flix (see [NAD V. Net­flix](http://www.3playmedia.com/2015/07/23/nad-v-netflix-ada-lawsuit-requires-closed-captioning-on-streaming-video/)) have been the sub­ject of law­suits based on this; but it’s also just good busi­ness to allow as many peo­ple as pos­si­ble access to your com­pa­ny’s prod­uct or service.

If you plan on work­ing on a web­site for US Fed­er­al or State gov­ern­ments (which includes edu­ca­tion­al insti­tu­tions), the [Web­site Acces­si­bil­i­ty Under Title II of the ADA](https://www.ada.gov/pcatoolkit/chap5toolkit.htm) doc­u­ment out­lines the acces­si­bil­i­ty man­dates for web­sites. Even pub­lic com­pa­nies may very well need to com­ply with the ADA; check out the [Does your web­site need to be ADA com­pli­ant?](http://www.logicsolutions.com/does-website-need-ada-compliance/) arti­cle for details.

I’m just going to assume that you want to make your web­site acces­si­ble for the prac­ti­cal rea­sons men­tioned above that go beyond legal com­pli­ance. Like many of the top­ics that I’ve dis­cussed before, this is all about _mak­ing the web bet­ter_.

<aside>
                                Both per­for­mance <span>&amp;</span> acces­si­bil­i­ty are not about padding pro­pos­als; they are about mak­ing web­sites that are more effec­tive for both our clients, and their customers.
                            </aside>

This is also how we should sell acces­si­bil­i­ty to our clients, sim­i­lar to how we talked about sell­ing per­for­mance in the [A Pret­ty Web­site Isn’t Enough](https://dev.to/gaijinity/a-pretty-website-isn-8217-t-enough-1nbj-temp-slug-3932740) arti­cle. We should build acces­si­bil­i­ty into our pro­pos­als, and inte­grate it into our design & devel­op­ment work­flow. Edu­cate clients on why it is impor­tant, and they’ll quick­ly get on board.

![Velvet Rope Let People In Accessibility](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_992x558_crop_center-center_82_line/velvet-rope-let-people-in-accessibility.jpg)

The [Per­sonas for Acces­si­ble UX](http://rosenfeldmedia.com/a-web-for-everyone/personas-for-accessible-ux/) arti­cle is a super-use­ful resource for under­stand­ing the type of dis­abil­i­ties peo­ple may have, and how that impacts their abil­i­ty to access your web­site. Take the time to read through the per­sonas list­ed there, and come back when you’re done.

Real­ly, it’s worth it. I’ll wait.

## Major Use Cases

So here’s a non-exhaus­tive syn­op­sis of the dis­abil­i­ties that peo­ple may encounter with your web­site (cribbed from [here](https://github.com/dpersing/ada-a11y-intro/blob/master/a11y-presentation.md)):

- Vision (blind­ness, low vision, col­or blindness)
  - Over 6,500,000 adults, most of them between 18 and 64, and over 650,000 chil­dren in the US report­ed issues relat­ed to low vision or blind­ness in 2011.
  - About 1 in 10 men are col­or blind.
- Hear­ing (deaf­ness)
  - About 36 mil­lion adults in the US have some form of hear­ing loss.
  - About 2 in 1000 chil­dren in the US are born deaf.
- Motor skills (trou­ble with using a mouse)
- Cog­ni­tive and learn­ing issues (autism, dyslex­ia, ADD, etc.)
  - About 1 in 88 chil­dren in the US are on the autism spectrum.
  - Prob­a­bly about 20% of peo­ple have some form of dyslexia.
  - 11% of chil­dren 4 – 17 years of age, and about 4% of adults, in the US have been diag­nosed with ADD.

In gen­er­al, it’s esti­mat­ed that 12 – 20% of peo­ple have a dis­abil­i­ty of some kind.

So let’s do some­thing about it!

## Pa11y as Tool­ing for Accessibility

Actu­al­ly mak­ing web­sites acces­si­ble isn’t that hard; the hard part is know­ing _what_ you should be doing. While there are some web-based tools out there, I’ve found that the <kbd>npm</kbd> pack­age [Pa11y](https://www.npmjs.com/package/pa11y) to be the most up to date and effec­tive tool for me.

Pa11y is just a CLI lay­er on top of [HTML\_​CodeSniffer](http://squizlabs.github.io/HTML_CodeSniffer/), which enforces the three con­for­mance lev­els of the [Web Con­tent Acces­si­bil­i­ty Guide­lines (WCAG) 2.0](http://www.w3.org/TR/WCAG/), and the web-relat­ed com­po­nents of the [U.S. ​“Sec­tion 508” leg­is­la­tion](https://www.section508.gov/).

So let’s talk about how to use it.

<aside>
                                The abbre­vi­a­tion #a<span>11</span>y is often used for <span></span>​<span>“</span>acces­si­bil­i­ty”, where the num­ber <span>11</span> refers to the num­ber of let­ters omit­ted from <span></span>​<span>“</span>acces­si­bil­i­ty”
                            </aside>

I’ll state right upfront that I’m no expert on acces­si­bil­i­ty; if you want to do a deep-dive on acces­si­bil­i­ty, check out the [Get­ting Start­ed with Web Acces­si­bil­i­ty](https://www.w3.org/WAI/gettingstarted/) & [Using Aria](https://w3c.github.io/using-aria/) resources. But if you use [seman­tic HTML5 ele­ments](https://www.w3schools.com/html/html5_semantic_elements.asp), use a prop­er head­ing hier­ar­chy, and use <kbd>alt</kbd> attrib­ut­es for images, you’re halfway home.

For the rest of it, <kbd>pa11y</kbd> gives you a very easy to under­stand list of what’s bro­ken, and how to fix it. It’s very sim­i­lar to using the [WC3 Val­ida­tor](https://validator.w3.org/) to check your HTML for cor­rect­ness, so it’s not hard to get going on a bul­let-point­ed list of things to fix.

![Kintsugi Fix Whats Broken](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x675_crop_center-center_82_line/kintsugi-fix-whats-broken.jpg)

You will need to have [Node](https://nodejs.org/) & [NPM](https://www.npmjs.com/) (or [Yarn](https://yarnpkg.com/en/)) installed in order to take advan­tage of it, but hope­ful­ly you’re already up to speed using these tools. If you’re not, def­i­nite­ly con­sid­er get­ting on the band­wag­on, because fron­tend devel­op­ment is mov­ing inex­orably towards them.

So the first thing we’ll do is install a pack­age called [npx](https://www.npmjs.com/package/npx); this lets you run node mod­ules with­out hav­ing to install them (either glob­al­ly or as part of a pack­age), either via <kbd>npm</kbd> or <kbd>yarn</kbd>:

```

sudo npm install -g npx



sudo yarn global add npx

```

We’re installing the <kbd>npx</kbd> pack­age glob­al­ly, so we’re using <kbd>sudo</kbd> to make it hap­pen; but you can also con­sid­er check­ing out how to [install pack­ages glob­al­ly with­out sudo](https://github.com/sindresorhus/guides/blob/master/npm-global-without-sudo.md) if you choose to, or per­haps don’t have <kbd>sudo</kbd> access.

Of course, if you like you can add <kbd>pa11y</kbd> as a depen­den­cy in your project as well, if you pre­fer to do it that way. You could even install <kbd>pa11y</kbd> glob­al­ly, the same way we did with <kbd>npx</kbd>. But I want­ed to intro­duce using <kbd>npx</kbd> as a gen­er­al way to exe­cute Node mod­ules with­out hav­ing to install them.

<kbd>npx</kbd> also has a spe­cif­ic ben­e­fit in this case: it’ll make sure we’re always run­ning the lat­est <kbd>pa11y</kbd> with the lat­est rule­sets, with­out hav­ing to keep it up to date.

## Fix­ing Acces­si­bil­i­ty Problems

So now that we have <kbd>npx</kbd> installed, we can run <kbd>pa11y</kbd> and gets its eval­u­a­tion of the acces­si­bil­i­ty of our web­site! We’ll use the [blog page](https://nystudio107.com/blog) of this very web­site as our guinea pig for acces­si­bil­i­ty issues:

![Guinea Pig Test](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x675_crop_center-center_82_line/guinea-pig-test.jpg)

To run <kbd>pa11y</kbd>, we can just do:

```

npx pa11y --standard "WCAG2AA" --ignore "notice;warning" https://nystudio107.com/blog

```

We’re telling it that we don’t want to see any <kbd>notice</kbd>s or <kbd>warning</kbd>s, but rather just errors. If you want to do a more com­pre­hen­sive check, you can show the <kbd>warning</kbd>s too, by omit­ting it from the command.

Out of the box, <kbd>pa11y</kbd> sup­ports 4 acces­si­bil­i­ty stan­dards: <kbd>Section508</kbd>, <kbd>WCAG2A</kbd>, <kbd>WCAG2AA</kbd>, <kbd>WCAG2AAA</kbd>. The default is <kbd>WCAG2AA</kbd>, but you can spec­i­fy any stan­dard you want via the <kbd>--standard</kbd> com­mand line argument.

All of the <kbd>WCAG2*</kbd> stan­dards are the same inter­na­tion­al stan­dard, but with dif­fer­ent lev­els of strict­ness (<kbd>A</kbd> being the least strict, <kbd>AAA</kbd> being the most strict). Addi­tion­al infor­ma­tion on WCAG lev­els can be found in [Under­stand­ing Lev­els of Con­for­mance](https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head).

The <kbd>Section508</kbd> stan­dard is for US Fed­er­al & State gov­ern­ment insti­tu­tions, should you be work­ing on web­sites for them.

But we’re just going to use the default <kbd>WCAG2AA</kbd> stan­dard, which is mid­dle of the road in terms of strict­ness (and indeed is the stan­dard that WCAG sug­gests to use), and is used by default if we don’t spec­i­fy a <kbd>--standard</kbd>.

Here’s what the out­put looks like:

```

vagrant@homestead:~$ npx pa11y --ignore "notice;warning" https://nystudio107.com/blog
Welcome to Pa11y

 > PhantomJS browser created
 > Testing the page "https://nystudio107.com/blog"

Results for https://nystudio107.com/blog:

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nav-menu > div > div:nth-child(1) > div > div > a
   └── <a href="/"><svg xmlns="http://www.w3.org/2...</a>

 • Error: This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 4.5:1, but text in this element has a contrast ratio of 2.93:1. Recommendation: change background to #3c3d3f.
   ├── WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail
   ├── #nav-menu > div > div:nth-child(3) > ul > li:nth-child(2) > a
   └── <a href="/blog" class="nav-link">Blog</a>

 • Error: This text input element does not have a name available to an accessibility API. Valid names are: label element, title attribute.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputText.Name
   ├── #searchbox
   └── <input type="text" id="searchbox" placeholder="search" autocomplete="off" class="autocomplete-input">

 • Error: This form field should be labelled in some way. Use the label element (either with a "for" attribute or wrapped around the form field), or "title", "aria-label" or "aria-labelledby" attributes as appropriate.
   ├── WCAG2AA.Principle1.Guideline1_3.1_3_1.F68
   ├── #searchbox
   └── <input type="text" id="searchbox" placeholder="search" autocomplete="off" class="autocomplete-input">

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(1) > div > a
   └── <a href="/"> <svg class="scaling-svg sub-lo...</a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(1)
   └── <a class="social" href="mailto:info@nystudio107.com"><i class="icon-mail-alt"></i></a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(2)
   └── <a rel="nofollow" class="social" href="https://www.facebook.com/newyorkstudio107"><i class="icon-facebook"></i></a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(3)
   └── <a rel="nofollow" class="social" href="https://twitter.com/nystudio107"><i class="icon-twitter"></i></a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(4)
   └── <a rel="nofollow" class="social" href="https://github.com/nystudio107"><i class="icon-github-circled">...</a>

 • Error: Iframe element requires a non-empty title attribute that identifies the frame.
   ├── WCAG2AA.Principle2.Guideline2_4.2_4_1.H64.1
   ├── #Smallchat > iframe
   └── <iframe data-reactroot="" style="z-index: 999999999; position: fixed; right: 0px; bottom: 0px; border: 0px; background-image: none; transition: width 200ms cubic-bezier(0.25, 0.25, 0.5, 1), height 200ms cubic-bezier(0.25, 0.25, 0.5, 1); -webkit-trans...

10 Errors
0 Warnings
0 Notices

```

What it actu­al­ly does is pret­ty nifty: it fires up a ​“head­less” brows­er, ren­ders your web­page in it cour­tesy of [Phan­tomJS](http://phantomjs.org/), and then ana­lyzes it for acces­si­bil­i­ty issues. This is pret­ty sim­i­lar to how Crit­i­cal CSS is gen­er­at­ed, as per the [Imple­ment­ing Crit­i­cal CSS on your web­site](https://dev.to/gaijinity/implementing-critical-css-on-your-website-37d5-temp-slug-6012917) article.

In any event, that’s quite a num­ber of errors, so let’s take them one by one!

```

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nav-menu > div > div:nth-child(1) > div > div > a
   └── <a href="/"><svg xmlns="http://www.w3.org/2...</a>

```

This can be fixed by adding a <kbd>&lt;title&gt;homepage&lt;/title&gt;</kbd> as a child of the <kbd>&lt;svg&gt;</kbd> that is dis­played inline in the glob­al site head­er, so there’s some text for screen read­ers to parse. Link tar­gets for screen read­ers should say _where_ the link will take them, or _what_ click­ing on the link will do, not describe what the thing inside the link is (a logo, in this case).

Just imag­ine some­one read­ing the web­page aloud to you, if they said ​“link nystudio107 logo” you’d have no idea what click­ing on it does. If instead they said ​“link home­page” then you’d get it.

Anoth­er way that this issue can also be resolved is by putting text inside of the <kbd>&lt;a&gt;</kbd> tag that is invis­i­ble to the eye, but screen read­ers will pick up. We can do this with a <kbd>&lt;span class="sr-only"&gt;</kbd> using the CSS from Twit­ter Bootstrap:

```

.sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0,0,0,0);
    border: 0;
}

```

That way, screen read­ers will have some­thing to read!

```

 • Error: This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 4.5:1, but text in this element has a contrast ratio of 2.93:1. Recommendation: change background to #3c3d3f.
   ├── WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail
   ├── #nav-menu > div > div:nth-child(3) > ul > li:nth-child(2) > a
   └── <a href="/blog" class="nav-link">Blog</a>

```

This is say­ing that the con­trast ratio between our menu links and the head­er back­ground col­or isn’t high enough. It sug­gests chang­ing it from <kbd>#58595b</kbd> to <kbd>#3C3D3F</kbd> to increase the con­trast ratio. This is to assist with read­abilty for peo­ple who have vision problems.

Since these are the nystudio107 brand­ing col­ors, the prob­lem could have been mit­i­gat­ed by apply­ing the tips from the arti­cle [Tips on Design­ing for Web Acces­si­bil­i­ty](https://www.w3.org/WAI/gettingstarted/tips/designing) dur­ing the design process.

```

 • Error: This text input element does not have a name available to an accessibility API. Valid names are: label element, title attribute.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.InputText.Name
   ├── #searchbox
   └── <input type="text" id="searchbox" placeholder="search" autocomplete="off" class="autocomplete-input">

 • Error: This form field should be labelled in some way. Use the label element (either with a "for" attribute or wrapped around the form field), or "title", "aria-label" or "aria-labelledby" attributes as appropriate.
   ├── WCAG2AA.Principle1.Guideline1_3.1_3_1.F68
   ├── #searchbox
   └── <input type="text" id="searchbox" placeholder="search" autocomplete="off" class="autocomplete-input">

```

This is say­ing that our <kbd>&lt;input&gt;</kbd> ele­ment used for site search lacks a <kbd>aria-label</kbd> attribute for screen read­ers. This can be fixed by adding them to our [vue2-auto­com­plete](https://github.com/nystudio107/vue2-autocomplete) Vue component.

```

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(1)
   └── <a class="social" href="mailto:info@nystudio107.com"><i class="icon-mail-alt"></i></a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(2)
   └── <a rel="nofollow" class="social" href="https://www.facebook.com/newyorkstudio107"><i class="icon-facebook"></i></a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(3)
   └── <a rel="nofollow" class="social" href="https://twitter.com/nystudio107"><i class="icon-twitter"></i></a>

 • Error: Anchor element found with a valid href attribute, but no link content has been supplied.
   ├── WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.NoContent
   ├── #nys-footer > div > div > div > div:nth-child(2) > a:nth-child(4)
   └── <a rel="nofollow" class="social" href="https://github.com/nystudio107"><i class="icon-github-circled">...</a>

```

These all refer to the social icons at the bot­tom of the screen, which are a cus­tom icon font cour­tesy of [Fontel­lo](http://fontello.com/) (gen­er­at­ed via our [Gulp](https://www.npmjs.com/package/gulp-fontello) task). Con­trary to pop­u­lar belief, icon fonts can work with accessibility.

We just need to change the links to be like this:

```

<a rel="nofollow" class="social" href="https://www.facebook.com/newyorkstudio107">
    <i class="icon-facebook" aria-hidden="true" title="Facebook"></i>
    <span class="sr-only">Facebook</span>
</a>

```

The <kbd>aria-hidden</kbd> attribute caus­es screen read­ers to skip the ele­ment, and the <kbd>title</kbd> attribute gives sight­ed peo­ple a mouseover tooltip. Then the <kbd>&lt;span class="sr-only"&gt;</kbd> pro­vides the text for screen read­ers to parse, using the CSS from Twit­ter Bootstrap:

```

.sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0,0,0,0);
    border: 0;
}

```

That’s all there is to it, we now have nice acces­si­ble social icons.

```

 • Error: Iframe element requires a non-empty title attribute that identifies the frame.
   ├── WCAG2AA.Principle2.Guideline2_4.2_4_1.H64.1
   ├── #Smallchat > iframe
   └── <iframe data-reactroot="" style="z-index: 999999999; position: fixed; right: 0px; bottom: 0px; border: 0px; background-image: none; transition: width 200ms cubic-bezier(0.25, 0.25, 0.5, 1), height 200ms cubic-bezier(0.25, 0.25, 0.5, 1); -webkit-trans...

```

This one, unfor­tu­nate­ly, we can’t fix… because it’s com­ing from the [Small­chat](https://small.chat/) library we use to allow site vis­i­tors to con­tact us via [Slack](https://slack.com). How­ev­er what we _can_ do is con­tact the authors of Small­chat, and point out the acces­si­bil­i­ty issues, so that they can fix them. Then _every­one_ benefits.

## Automat­ing Acces­si­bil­i­ty Testing

The cool thing about <kbd>pa11y</kbd> being a Node mod­ule is that we can inte­grate it into our fron­tend work­flow, and auto­mate test­ing. Take for exam­ple this <kbd>a11y</kbd> Gulp task:

```

// Process data in an array synchronously, moving onto the n+1 item only after the nth item callback
function doSynchronousLoop(data, processData, done) {
    if (data.length > 0) {
        const loop = (data, i, processData, done) => {
            processData(data[i], i, () => {
                if (++i < data.length) {
                    loop(data, i, processData, done);
                } else {
                    done();
                }
            });
        };
        loop(data, 0, processData, done);
    } else {
        done();
    }
}

// Run pa11y accessibility tests on each template
function processAccessibility(element, i, callback) {
    const accessibilitySrc = pkg.urls.critical + element.url;
    const cliReporter = require('./node_modules/pa11y/reporter/cli.js');
    const options = {
        log: cliReporter,
        ignore:
                [
                    'notice',
                    'warning'
                ],
        };
    const test = $.pa11y(options);

    $.fancyLog("-> Checking Accessibility for URL: " + $.chalk.cyan(accessibilitySrc));
    test.run(accessibilitySrc, (error, results) => {
        cliReporter.results(results, accessibilitySrc);
        callback();
    });
}

// accessibility task
gulp.task("a11y", (callback) => {
    doSynchronousLoop(pkg.globs.critical, processAccessibility, () => {
        // all done
        callback();
    });
});

```

This pig­gy­backs off of the <kbd>package.json</kbd> set­up we out­lined in the [A Bet­ter package.json for the Fron­tend](https://dev.to/gaijinity/a-better-package-json-for-the-frontend-1gal-temp-slug-5184040) arti­cle, and uses the urls we already have in the <kbd>pkg.globs.critical</kbd> object from the [Imple­ment­ing Crit­i­cal CSS on your web­site](https://dev.to/gaijinity/implementing-critical-css-on-your-website-37d5-temp-slug-6012917) article.

We already have a URL to each major tem­plate our site uses for our Crit­i­cal CSS gen­er­a­tion, we can use them again to run our <kbd>pa11y</kbd> checks on every tem­plate on our website!

For this to work, you’ll need to do <kbd>npm install pa11y -D</kbd> or <kbd>yarn add pa11y -D</kbd> to add <kbd>pa11y</kbd> to our pro­jec­t’s <kbd>package.json</kbd>, but then we’re good to go!

So now we can just do <kbd>gulp a11y</kbd> and it’ll test our entire web­site for acces­si­bil­i­ty issues. Nice!

## Wrap­ping Up

Just use <kbd>pa11y</kbd> the way you use any oth­er audit­ing tool: you get a list of things to fix, you address them, and then you re-run the test. Lath­er, rinse, repeat until all of the issues you plan to address are tak­en care of.

One real­ly nice thing from a best prac­tices point of view is that if we’ve addressed SEO best prac­tices as per the [Mod­ern SEO: Snake Oil vs. Sub­stance](https://dev.to/gaijinity/modern-seo-snake-oil-vs-substance-4l5k-temp-slug-8632935) arti­cle, we’ve already tak­en care of a num­ber of acces­si­bil­i­ty issues. Both SEO and acces­si­bil­i­ty want <kbd>alt</kbd> tags for images, for instance. Nice.

It makes sense if you think about it; search engines are essen­tial­ly screen read­ers. But it’s great to see the con­ver­gence of tech­niques that fall under the best prac­tices umbrella.

That’s it! It was­n’t so bad at all to address these things, and we prob­a­bly made a big dif­fer­ence to some peo­ple vis­it­ing our site.

![Freedom Through Web Accessibility](https://nystudio107-ems2qegf7x6qiqq.netdna-ssl.com/img/blog/_1200x675_crop_center-center_82_line/freedom-through-web-accessibility.jpg)

Acces­si­bil­i­ty isn’t some­thing that’s ter­ri­bly dif­fi­cult to address, espe­cial­ly if you inte­grate it as part of your design & devel­op­ment process, and use tools like <kbd>pa11y</kbd> to help you along the way.

As with any­thing, it’s much eas­i­er to build projects with acces­si­bil­i­ty in mind than it is to retroac­tive­ly add it. So make it part of your design & devel­op­ment process.

It’s also worth not­ing that [Pa11y](https://github.com/pa11y) also has some oth­er cool projects based on it, such as [Pa11y Dash­board](https://github.com/pa11y/dashboard) and [Pa11y Web­ser­vice](https://github.com/pa11y/webservice) for more auto­mat­ed mon­i­tor­ing of your web­site’s acces­si­bil­i­ty. If you pre­fer GUI tools, check out [Chrome Acces­si­bil­i­ty Devel­op­er Tools](https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en) and [HTML\_​Codesniffer](http://squizlabs.github.io/HTML_CodeSniffer/).

Go make some inclu­sive websites!

## Further Reading

_If you want to be notified about new articles, follow [nystudio107](https://twitter.com/nystudio107) on Twitter._

<small>Copyright ©2020 nystudio107. Designed by nystudio107</small>