I’ve recently been working on “retrofitting” an old site I built some years ago to be 508 compliant. It has been an interesting learning process, going from knowing very little about it, to wanting to learn more. Even though there is a lot of information out there on the internet about 508 compliance, I thought I’d write a basic synopsis for those of you who are not yet ready to dive into the white papers but who were just kind of curious about the subject.
In 1998, the US Congress amended the 1973 Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities. Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. Under Section 508, agencies must give disabled employees and members of the public access to information that is comparable to the access available to others.–Wikipedia
What does this mean and how does it impact web developers?
Close your eyes for a moment and imagine that you are unable to see. How do you look up information on the internet? Many people with low vision or no vision use something called a “screen reader*,” which speaks the information out loud for them. However, in order for the reader to be able to read what’s on the site, the code needs to be structured in an organized way with, at the least, a hierarchy of header tags used throughout the page, i.e. <H1>, <H2>, <H3>, etc., indicating the information’s order of importance. Without basic header tags, the reader may skip over important information completely.
Below is an example of a screen reader called Fangs.
Likewise, when the screen reader comes across a photo, it is not enough to write an alt tag that says, “a photo of a cathedral.” Hearing that spoken aloud by the screen reader, the user gets no mental feedback at all about that cathedral. A better description might be, “a photo of the east façade and the giant rose window of the gothic Notre Dame Cathedral in Paris, France, completed in 1163.” It could get even more detailed, but at least now the user has a much better idea of what s/he would be seeing if s/he could see. The only case where you would not want to use an alt tag is when the image is for decorative purposes only. A tag might end up confusing the screen reader user. In this case, it is best to leave an empty alt tag. See at the link below an example of the correct usage of alt tags:
Properly written links are another basic area to consider. Instead of using links saying “more” or “click here” which offer little or no clue as to what will happen when a screen reader user clicks on them, a better way is to use a descriptive phrase such as, “please click here for membership information,” or, “more information on Leonardo da Vinci’s Mona Lisa.” E-mails should be dealt with in a similar fashion, so instead of using a simple e-mail link: firstname.lastname@example.org a better format would be: “e-mail My Pawprint Productions (email@example.com).”
A very important, yet often overlooked, item to consider when developing a site is the color scheme. Personally, I have a tendency to shy away from using jet black type for text. Maybe it’s because I’ve worked on a lot of art museum and gallery type sites, where aesthetics and color use are valued more highly perhaps than on a site selling garden hoses, for example! However, I quickly learned that the site I had built for a client may have looked nice but the grayish brown text on a beige background did not offer enough contrast to be read by visitors with low vision. A 508 consultant I was working with shared a color contrast tool, which is a little piece of software that is invaluable when making your color choices. The particular software I used was called Colour Contrast Analyser (British spelling intended!), which can be downloaded for free here:
With free color contrast software out there, there is no excuse not to be using it! You can still choose colors you like but you may have to go a bit darker or a bit lighter than you might have liked. If I was able to get over it, so can you!
I’ve mentioned how to treat images, links, and color contrast in order for them to be 508 compliant, but what about language? The main language of any site should be identified at the very beginning of your code in <html> tag, before <head>, like this: <html lang=”en”> (English, for example). This tells the screen reader that the main language of the site is English. If there are any foreign language words within the pages, they can be identified by wrapping this code around the word: <span lang=”fr”>french word</span> (changing the “fr” to “es” (spanish), “it” (italian), “de” (german), etc. If it’s an entire sentence, use the code within the <p> tag this way: <p lang=”es”> Spanish sentence…</p> (Spanish). For more on foreign language use in 508 compliance, take a look at this easy to read article by Emily Coward:
Here’s a pretty comprehensive list of language codes:
Beyond the fairly straightforward 508 compliance methods mentioned so far, there is a new technology emerging, albeit not yet widely adopted by developers, called ARIA (Accessible Rich Internet Applications) landmark roles. Basically ARIA roles are a set of specialized “landmark” roles that are designed to improve accessibility for people using screen readers. Currently screen reader users employ a list of shortcut keys to get around the page, which is great, but there isn’t always enough information available about the purpose of the content when you reach it. Using the same shortcut keys, ARIA bridges the gap by announcing each landmark area by a more descriptive name such as “banner landmark” or “main content landmark,” instead of just “a heading.” It’s a chicken and egg situation though. Until more developers start adopting ARIA landmark roles, screen reader users will continue to rely on the tried and trusted method of jumping from header to header through the content. If and/or when more developers start using the technology in a consistent way throughout sites, more screen reader users will be encouraged to switch to using ARIA to navigate sites and probably have a much better experience in the process.
But, wait! Don’t we already use the new HTML5 tags to clearly specify the different sections of a web page? i.e. what is the difference between HTML5 (e.g. , , , and ) and ARIA (e.g. , , and ) and when do we use them? ARIA is not a version of HTML. It is an extension of the capabilities of HTML by adding new attributes. Most of the ARIA specification is intended for use in web applications, rather than in static web content, but some of the ARIA roles overlap with some of the new HTML 5 elements. The answer is that we can use both. For a more detailed discussion on the differences, read this article:
Another use of ARIA is to avoid repetitious text for the screen reader. Normally, when you use an image with a caption, you would insert an alt tag on the image with the same/similar info as in the caption. However, a screen reader reads everything, including the invisible text sighted users do not see, thus reading the text twice and making for a tedious experience if there are many images. By inserting the following code: aria-describedby=”” in tandem with an id=”” tag and a specific reference number the text will only be read once:
<div><img src=”images/still-life.jpg” aria-describedby=”still-life-1″ /></div>
<p class=”caption2″ id=”still-life-1″>Above: Pablo Picasso, Still Life, 1943, gouache on paper</p>
For those of you who may be interested in adopting ARIA, here is a list of available landmarks you can use:
- application – A region declared as a web application, as opposed to a web document.
- banner – A region of site specific content, such as the identity of the site sponsor, etc.
- complementary – A supporting section of the document, designed to be complementary to the main content. Example: Sports News and Business News on a typical news page. It should be meaningful when separated from the main content
- contentinfo – A large region that contains information about the parent document. Example: footer of copyrights and links to privacy statements.
- form – A region of the document that represents a collection of form elements. (In HTML the HTML form element can be used instead). Note: you should use the search role and not the generic form role for search forms.
- main – The main content of the document. Typically following the navigation regions.
- navigation – A collection of navigational elements. Example: a left navigation area.
- search – A region that contains a search widget.
And here is the site from which this list was taken, which also explains different uses of ARIA:
Not all disabilities require a screen reader
We mustn’t forget that there are other disability types, such as motor, auditory, cognitive, etc., whose needs are just as relevant. Take a person who can see just fine but has a physical disability rendering them unable to manipulate a mouse and must rely on the keyboard alone to navigate web pages. The need for clearly organized code in web pages is equally important to them as to the screen reader user. For example, without heading tags in the code of the web page, the user cannot tab through the web page headings at all. Put simply, a keyboard user must be able to do all the same things on a web page that someone using a mouse can do.
An essential little bit of code for people with such disabilities, is the “skip to main content” link, which may be visible (encouraged) or invisible, depending on your particular desires. Imagine how tiring it would be if you had no arm movement and had to use your head to click on a button or use a stick in your mouth to click on the keyboard in order to advance through a web page. With the amount of items in the upper portion of a web page to plow through, such as corporate logos, search bars, navigation bars, etc., before reaching the main content, it would be unacceptable not to have this piece of code. The reason it is encouraged to make the code visible is mainly for the benefit of these sighted disabled users. If the code is hidden, they have no way of knowing it’s even there (a screen reader would read it out for a non-sighted person) so they cannot tap on it. Some developers do not like the look of this link at the top of their sites so choose to hide it. One way around this push and pull between aesthetics and accessibility is to have the link hidden visually by default, but have it become visible when it receives keyboard focus. Here is an example of a government site (EPA) using the hidden to visible version of this code. When the page loads, click the Tab key and you’ll see “Jump to Main Menu” appear at the top:
If you’d like to learn more about using the “Skip to Content” link, this article walks you through all the ways of using it:
Is 508 Compliance a requirement these days?
While compliance with section 508 is not a requirement for commercial web sites in the United States, it is for all federal agency sites. This is pretty much the case in most countries with the exception of Australia who require government and commercial sites to be compliant with their Disability Discrimination Act. The laws for state and local government activities and agencies is the Title II. The law is slightly different and the Department of Justice oversees the compliance of Title II complaints and violations. Below is a link to a page, posted by Mark Rogers, showing the state of government accessibility standards around the world:
More private sector sites, such as museums and galleries, however, are adopting some or all of the section 508 standards in order to make their online “experiences” available to a wider audience. The challenge is maintaining the balance between an engaging interactive multimedia experience with a pleasing aesthetic and one that is accessible and useful to as many people as possible. There is not a wealth of data out there on screen reader usage. However, in a study carried out by WebAIM in January 2014, which had a relatively small sample group, 81.3% of respondents said that better, more accessible web sites would have a bigger impact on improvements to web accessibility as opposed to only 18.7% who thought better assistive technology would be more helpful. So why don’t more developers answer the call? In the same study, almost 40% of respondents attributed lack of awareness of web accessibility and lack of web accessibility skills or knowledge as the top two reasons that so many developers did not create accessible web sites. Those two reasons were closely followed by a fear that accessibility will hinder the look, feel, or functionality of the site and lastly lack of budget came in the lowest at only 8.5%.
This is by no means an exhaustive study of 508 compliance, but hopefully it will tweak your interest and make you want to find out more!
*JAWS is currently the most popular screen reader, though VoiceOver, NVDA, and SystemAccess are becoming much more popular due to their features and low cost.
By Pam Muirheid, My Pawprint Productions