A very common pattern on the web is to overlay text on a photo. It’s a lovely effect but one that requires care to get right.
The difficulty arrises for the web developer wishing to produce an accessible site because they can never be sure what the colour of the photo will be.
I’m in London visiting friends for a couple of weeks and, predictably enough, took them to see West End production of Hamilton the Musical. Unfortunately one of my friend’s health has deteriorated over the last few years so queuing for entry to the theatre is a problem. We needed an access ticket.
This doesn’t feel like an access ticket, it feels like a VIP ticket.
Anyone who has attempted to navigate a web page using the keyboard, will have experienced sites that remove the default a:focus style without adding in a replacement.
The cause – but not the fault – lays with Eric Meyer’s original CSS reset, subsequently included in the YUI CSS framework, among others.
For most of my career as a web developer I’ve produced websites that work without JavaScript. For the JavaScript impaired the sites may be missing a minor visual feature or be a little clunky in places, but they work and the meaning remains clear. It doesn’t bother me that, sometimes, the cost of allowing for sites to load without JavaScript can mean missing out on the latest web fashion. I’m not a big fan of fashion.
Currently, web development is undergoing some major transitions: the HTML5 spec is being developed and CSS3 is being implemented. The browser wars have returned, although this time around, it’s a battle to win developers’ hearts by implementing the newest standards.
Now is the time for developers to re-evaluate their past practices; moving on from the old and embracing the new. I kept that ethos in mind when upgrading the Soupgiant WordPress base theme recently. Among other things we were porting it to HTML5.
Big Red Tin co-author, Josh, and I were discussing the positioning of Skip to Content links on a website. In the past I’ve placed these in the first menu on the page, usually positioned under the header.
According to the fangs plugin, the JAWS screen reader reads the opening of Soupgiant.com as:
Page has seven headings and forty-three links Soupgiant vertical bar Web Production dash Internet Explorer Heading level one Link Graphic Soupgiant vertical bar Web Production Heading level five Heat and Serve Combine seventeen years of web production experience, twenty years of television and radio experience, put it all in a very large pot on a gentle heat. Stir regularly and serve. Soupgiant goes well with croutons and a touch of parsley.List of five items bullet This page link Skip to Content bullet Link Home bullet Link About bullet Link Contact bullet Link Folio
– my emphasis
That’s a lot of content to get through, on every page of the site, before the Skip to Content link. It would be much better if the skip to content link were earlier on the site.
As the HTML title of the page is read out by JAWS, the best position would be before the in-page title. The opening content would then read as:
Page has seven headings and forty-three links Soupgiant vertical bar Web Production dash Internet Explorer This page link Skip to Content Heading level one Link Graphic Soupgiant vertical bar Web Production
– again, the emphasis is mine
That gives the JAWS user the title of the page and immediately allows them to skip to the page’s content. I don’t read the header of on every page of a site, nor should I expect screen reader users to.
I realise screen readers most likely have a feature to skip around the page relatively easily, regardless of how the page is set up but our aim should not be relative ease, our aim should be absolute ease.
As a result, we’ve decided to move the skip to content links on future sites to earlier in the page.
Sadly, this revelation came up as a result of what I consider to be a limitation of the WordPress 3.0+ function wp_nav_menu, the inability to add items at the start of the menu. I should have considered the accessibility implications much earlier. It serves as a reminder, to all web developers, that we should constantly review our practices and past decisions.
