Working on Accessibility

Bean with Tools on the Ocean of Storms
Bean with Tools on the Ocean of Storms flickr photo by NASA on The Commons shared with no copyright restriction (Flickr Commons)

We’re taking a much deeper dive into accessibility lately. It is a fruitful and good thing to do but also one of those deceptively deep topics with lots of complications. As a result I’m learning a good bit so I better write it down before it’s all forgotten.

Two Handy Tools

Thanks to both Matt and Jeff, I ended up using a few different tools.1

Google’s Vox Plugin helps you get a better idea what the experience was going to be like for someone with issues seeing the website. Using this will enable you to understand exactly how some of your decisions play out. I found it very handy. As a minor warning, there appears to be no way to turn it off/on short of disabling the extension. Despite that, I really think it’s a good idea to spend some time using this tool. It really helps.

The other useful tool so far has been the Siteimprove Chrome extension. It’s pretty handy to see what warnings/failures are in play in each page. It’s led me to realize that there are so many problems.

Bits of Useful Code

One of VCU’s requirements is a text only view for the page. I figured that would be an existing WordPress plugin but it didn’t seem to be.2 So I have this mostly working plugin which I’ll be tweaking as we learn more. The javascript that does most of the work is below. It’s a bit ES6-y but you can see how this removes styles, images3, svgs, and any in-line css styles.

function removeStyles(){
	Array.from(document.querySelectorAll('link[rel="stylesheet"], style')).forEach((elem) => elem.parentNode.removeChild(elem)); //destroy the styles
}

function removeImages(){
	Array.from(document.querySelectorAll('img')).forEach((elem) => elem.parentNode.removeChild(elem)); //destroy the images
}

function removeSVG(){
	Array.from(document.querySelectorAll('svg')).forEach((elem) => elem.parentNode.removeChild(elem)); //destroy the SVG 
}

function removeInline(){
    Array.from(document.querySelectorAll('*')).forEach((elem) => elem.removeAttribute('style')); //destroy the inline css
}

Then I decided to deal with iframe embeds in a less ‘kill it with fire’ method as it seemed like they’d hold more valuable information and I didn’t want to destroy that. This will remove the iframe but create a functioning link. I don’t like that screen readers will then read that link letter by letter but I can’t figure out a decent way to get a useful title from totally unknown iframe structures. It seems better than just removing the content in terms of creating a comparable experience.

function removeIframe(){ //destroy iframes and replace with their internal URL as a link
    var frames = document.querySelectorAll('iframe'), i;
    for (i = 0; i < frames.length; ++i) {
      var link = document.createElement('a');
      link.href = frames[i].src;
      link.appendChild(document.createTextNode(link.href));
      frames[i].parentNode.replaceChild(link, frames[i]);
    }
}

I know this doesn’t solve all problems, for instance I haven’t dealt with pages which load images via javascript after the ‘text only’ button is pushed. There are also a number of other fringe cases which haven’t been seen to be dealt with but I think this is a start.

One other useful bit of CSS has to do with tabbed navigation and onfocus being visible. This example uses the default browser behavior but it does seem to ensure that it occurs. I haven’t tested it widely but it addressed the issue of tabbed navigation working but not being visible on a couple of our sites.

*:focus, *:active{
    outline: 5px auto -webkit-focus-ring-color;
    outline-offset: -2px;
}

The tabbed navigation itself is a bit odd to me. Chrome navigates between elements in a way that I expect. Vivaldi behaves in a similar manner. Safari requires a modifier key (option – thanks Matt) and Firefox has an advanced setting where you can activate keyboard navigation but I didn’t have much success with it working.

Questions

Alternate versions seem acceptable according to the rule makers. What I don’t know is how that plays out in this world of automated assessments. When Siteimprove or the Office of Civil Rights assesses your site, does the machine click the ‘high contrast’ button? There are some nice WordPress plugins that add functionality like that to the site. WP Accessibility is one we have running on several sites. I think that meets the standards but I get a bit more hesitant when I read the reasoning behind permitting alternate versions. I probably worry more about machine scans and then having to argue with people after the fact.

I have lots of questions about what kind of image shouldn’t have alt text. I tend to put fairly obscure images at the top of my blog posts. I don’t think do much more than add something visually amusing4. I’m more than happy to have alt text there but I wonder when it is simply annoying and what level of alt text is needed to actually convey information. The qualitative aspect vs the technical meeting of the standard is something that I want to understand better.


1 It is so very nice to work with people. Even with the Internet, having people around doing the same things is very pleasant and useful.

2 Cue Alan’s comment with a link to one he built in Fortran in 1992.

3 I might need to revisit this one and do something better with any existing alt text.

4 and probably just amusing to me