Quick A11y Fixes

Quick Accessibility Fixes

Tagged: jsTuesday, March 26, 2019

Some Quick Fixes for Old Sites

We had a very large Drupal website that contained thousands of pages some were still relevant but content had been created years ago, even before HTML5 standards were in place. During an Accessibility audit of the site, we used a tool called SortSite5 it identified a lot of errors across thousands of pages.

Obviously the content and markup of the site had not aged well, after reviewing the results accessibility scan some trends emerged. While most of the site needed a manual review to correct most the issues, there were a few things that can be 'hot fixed' with some javascript to clean them up until a human had time to edit the original content.

Removing Empty Tags with Javascript

One big issue was most of the site used a WYSIWIG editor (ckeditor) and there were a lot of non-visual tags on pages, which of course screen readers can see. These typically happen when someone is deleting some content, they don't notice that perhaps they left an empty <h1> or <a> tags wrapped around a nbsp or <br>. CKeditor and HTMLpurifier could catch most empty tags and remove them however its not perfect and what was left was giving us errors. Mostly line breaks left in links etc, not technically empty so I can see why they were being left by the text format cleaners.

Another reason for empty tags is Drupals Block system has titles for most of its blocks. These titles can have a <none> entry that is meant to not show a title, however the CMS actually just outputs a <h2></h2> tag.

To solve this, I quickly wrote up a snipped of javascript with jQuery to locate all these empty tags and remove them on page load, so at least screen readers won't be bothered by these tags until a human goes and corrects all the markup.

$("h1, h2, h3, h4, h5, h6, a").each(function() {
  var $this = $(this);
  if ($this.html().replace(/\s| /g, "").length == 0) {
    $this.remove();
    console.warn("autoFix: tag was removed by because it looks empty");
  }
});

Marking tables used for layouts with role of presentation

The second most common error was tables used incorrectly for layout reasons, mainly to create two column layouts. Tables for layout was really popular back in the day.

What I did here was look at all the tables on the page, and if they did not have headings, I would mark them with a presentation role. I first manually reviewed our content to make sure this would correct most of the issues, and not mark true tables as presentation. After spot checking I found over 90% of our tables when auto corrected were presentational tables.

$("table").each(function() {
  var $this = $(this);
  if ($this.children("thead").length == 0 && !$this.attr("role")) {
    $this.attr("role", "presentation");
    console.warn("autoFix: table was marked as presentation");
  }
});

These hot-fixes are not perfect, but the eliminated thousands of errors quickly, and free up developers to then move onto the next issue and revisit these at a later date to fix them correctly. We also used Google analytics to send events so we knew exactly which pages these hot-fixes were running on.