Inclusive web development
As a front end web developer working on websites for local authorities, I’m now acutely aware of the UK government accessibility regulations that apply to public sector websites and apps.
These regulations require meeting the extremely well documented WCAG 2.1 level AA accessibility guidelines.
Awareness of the guidelines is really all that the day-to-day website content editor needs. Awareness of such things as heading levels used semantically, rather than stylistically. Awareness of colour contrast ratios, ensuring text isn’t camouflaged against a similar background. Awareness of visual cues on a page, that give normal screen users contextual meaning, such as links saying “more…”.
For the website developer however, under the bonnet (or under the hood, if you think I mean old fashioned head attire) Assistive Technology such as screen reader software, can extract a whole other level of meaning from your pages. When you navigate to a new web page on the screen, you don’t take in every detail contained in the header, each time; you focus immediately on the prominent title and maybe skip ahead to the attention-grabbing feature in the centre.
Visually impaired users who use a screen reader to digest pages, soon gain an IT literacy that you and I are unfamiliar with. Such assistive technology offers keyboard shortcuts, to skip across the ‘primary landmarks’ of a page (the header, the search, the main navigation and the footer), or to navigate through the sections of the page just by listening to the title structure.
Some screen reader software can even extract all the links from a page, and then use them as a means for the user to skim through and find the necessary information. This is a good example where, as a web developer, we need to be conscious of HTML links that don’t actually go anywhere. For instance, in your navigation menu you may have an item that opens a sub-menu. You coded all items as links, because all the other items allow the user to navigate to another page, and you wouldn’t put a button in the middle, because it would look wrong. This is an example of where semantic HTML5 is actually missing a solution and so, the ARIA attributes come into play. Your anchor which only executes the action of dropping down sub-menu, simply needs the additional aria attribute of type=”button”. That fixes it! There is never any affect on styling, so it’s safe.
I mentioned visual cues earlier, for example a shopping cart button in your header could have the text “0” followed by an icon of a cart. Visually that’s pretty intuitive, but a screen reader might announce that as “0 picture of a cart”, which makes no sense at all. The solution is perhaps to have used CSS ‘float’ to rearrange the items, and to have chosen a more useful alternative text for our icon image. The screen reader will now announce this button as “shopping cart 0”, but we can still make that better. Adding punctuation in the ‘alt’ text will cause a pause, and adding an inline item such as a <span> which is then hidden from media=”screen” in the CSS, we have “shopping cart. 0 items”. A much better DESIGN for assistive technology, even though it is visually, completely unchanged.
Accessibility shouldn’t be an after-thought, it’s a whole branch of usability.
