Lack of accessibility testing

[glfmn]

Issue

I ran a simple test for accessibility and we have some issues, mostly down to a lack of labels for buttons and other content that would make our site screen reader friendly.

Replication

Click me! The site has an interactive demonstration of the issues (the site doesn't quite render properly so don't worry that it doesn't look exactly as expected).

Background

The web is built from the ground up with accessibility standards in mind. Lots of elements have attributes which are totally focused on accessibility: images have alternative text specifically so screen readers can offer a description to visually impaired web surfers. The official w3c spec is really dense, but luckily there are plenty of people that do this for a living that have lots of useful advice!

• survival guide
• w3c validator
• code like you give a damn
• mdn aria roles introduction

Steps to Completion

Luckily, many of these problems are already solved (or easily solved), with tools available on npm. Since we already use gulp we can add something like an accessibility lint.

Explore using gulp-accessibility

gulp-accessibility is a lint which catches accessibility errors in our html output, and lets us know where the issues are so we can fix them. It's relatively easy to install by just following the steps and then adding the snippet suggested in their documentation to start with:

gulp.task('test', function() {
  return gulp.src('./example/**/*.html')
    .pipe(access({
      force: true
    }))
    .on('error', console.log)
    .pipe(access.report({reportType: 'txt'}))
    .pipe(rename({
      extname: '.txt'
    }))
    .pipe(gulp.dest('reports/txt'));
});

The only problem is that by default it seems to generate a report in a text file, and we would rather have errors appear in the console (like a regular lint).

AccessLint

AccessLint is an accessibility service that integrates with github, but it's currently under development so it's a little shadowy. Explore the site, sign in, and see what's up!

checklist

• solve issues marked by web aim
• use aria roles where appropriate
• try gulp accessibility
• explore AccessLint
• look for other solutions!

Other thoughts

Should we add accessibility linting to travis-ci to reject pull requests which fail to meet accessibility standards for the front end?

[glfmn]

@HackFSU/web, thoughts?