Accessibility has been a fundamental aspect of good website design for many years.
There has been a wealth of new legislation which has made it necessary for companies to cater for those less able than themselves, and their website presence is just one aspect of that.
Early Principles for Web Accessibility
Changes to coding practices around the time of XHTML encouraged the use of markup text rather than text as images, for example, as a way of allowing screen readers to give as much information to disabled users as possible. Alt and title text are never as helpful as simple HTML text, and there are also benefits with organic SEO with this too.
Further ways of improving accessibility is by minimising code, allowing graceful degradation and also allowing users to entirely rely on their keyboard for those who find a mouse tricky to operate. Some accessible options can actually benefit users without impairments, such as tabbing on forms that many web users prefer for faster interaction.
HTML5 Additions for Web Accessibility
HTML5 has attempted to add more possibilities for accessibility and take further advantage of the software now available such as Screen Readers like JAWS. HTML5 is an expanding spec which has only recently started to approach completeness and, as such, support for it’s accessibility elements is only just starting to appear now.
HTML5 is aimed at producing an open web, where data is structured and usable by all manner of users, whatever their device and browser. There are many elements to HTML5 accessibility and these are explained below.
Semantic code aims to offer usable content even when certain presentational layers are missing or unsupported. One example might be a menu which can be coded as a list and this will be preserved if a stylesheet were to go missing. Semantic code should also make it easier for screen readers and other accessiblity software to process a page effectively for their users.
Modern web designs and developers aim to keep page content, presentation and interaction code as seperate to each as possible and this method helps the same page to be usable by different users on different devices.
Accessible Images, Rich Media, Audio & Video
Accessibility standards for images have been used for many years by most web developers, and for that reason are very well supported by accessibility software. They will typically search for an image’s alt tag, then it’s title tag and then finally read out the actual filename in an attempt to help those who can’t view the image themselves.
A recent fashion in web development is to include images as backgrounds, loaded in through CSS and this approach cannot provide alt text and the like. As such, it is not advisable to do this with images of importance, so that a screen reader is able to illustrate it’s significance to the user.
You can now use HTML5 role=”presentation”, for example, as additional aids but these are yet to be fully supported by the software that you would be targeting and so cannot be considered as an either/or option yet. The new <figure> tag with <figcaption> offers probably the best accessibility for using images with in content areas.
Accessible HTML5 Data Tables
Tables have traditionally been hard to support effectively for screen readers because of the visual nature in which data is represented through column and row headers. There were even many designers using tables for layout instead of their intended purpose but thankfully that is now a thing of the past.
HTML5 Data Tables include items which connect data better and this allows tables to make more sense to those who cannot easily look at them. For example, “headers=’columnName'” will match a row or column of data with it’s header. There is also the “scope” which can be used here to indicate a headed row. Table captions are also very much part of the spec too.
Accessible HTML5 Forms
Forms have always been key parts of most websites, and can be the first point of contact when creating sales leads, or may serve another function linked to revenue generation. Therefore, it makes sense that you build forms that as many people can easily complete as possible. Much testing will now be done around conversions and yet, still, making forms more accessible is a topic that can still sometimes be overlooked.
The <label> tag has been around for a long time from HTML4.0 through to XHTML and HTML5 and it continues to be a crucial basic requirement for building an accessible form. Labels clearly mark the link between the input and it’s title, ensuring data is entered correctly. Without this, users with poor eyesight may consistently receive error messages from their incorrect inputs and simply give up as a result.
There were many misuses of the <label> tag after it’s early inception, but thankfully most designers and developers now use it correctly. HTML5 also gave us new form elements such as
HTML5 also brings us the new autofocus attribute, plus items like novalidate and placeholder. There are several ARIAs available which duplicate some of that discussed here, and it may not be necessary to use both. One example might be the attribute “required” alongside “aria-required=’true'” which essentially do the same thing, only with the former being better supported currently.
Accessible Rich Internet Applications (WAI-ARIA) were defined by W3 and this spec is closely associated with the release of HTML5, though can be considered as a separate entity by itself. There are roles, plus states and properties but sometimes their use currently duplicate other methods which are more widely supported.
Existing Disability and Assistive Technology
JAWS remains one of the more popular choices for screen reading, though there are others available on different operating systems. Macs now come bundled with VoiceOver which has been significantly improved in recent years and in ensuring wide availability, Mac developers can even try out their own sites in it too.
HTML5 Accessibility Projects
- All code covers accessibility issues as standard.