Overview of Web Accessibility Tech Report
This is a technical report focusing on web accessibility and the user experience. This report covers topics such as the “who, what, and why”, and explore the web semantics/standards for accessibility. In addition this report features snippets of code to demonstrate what is and is not the correct way to code for accessibility. The purpose of this document is to educate why we should design our sites for accessibility, and a glimpse at the technical aspects of doing so. This brief glimpse into web accessibility covers only those who require a screen reader in order to browse the web.
What This Report Covers
- What Does It Mean To Be Accessible
- Who Benefits From Accessibility
- The Rehabilitation Act and Section 508
- Screen Readers
- Coding For The Blind
- CSS
- HTML Structuring
- Heading Tags
- Navigation
- Text Equivalents For Images
- Tables
- Forms
- WAI-ARIA & Landmark Roles
This report spans over 12 pages, and is meant to be a “brief” glimpse into designing for the visually impaired. It includes Section 508 provision references when needed. You can download the white paper from the link below for a more convenient and better structured reading experience, or continue on down the page for the full report.
Download White Paper
Web Accessibility User Experience Tech Report
Written By: Jeremy Proffitt
March 24th, 2015
WHAT DOES IT MEAN TO BE “ACCESSIBLE”?
The idea behind making your websites accessible is that all the functions and data are made available for anyone to use, regardless of their disabilities or whatever difficulties they may have. Some users are color blind, some are completely blind and depend on software such as “NVDA” or “JAWS” which are screen readers to help them navigate the page audibly while using keyboard shortcuts to navigate your pages.
In some cases being accessible requires you to include an option to switch your CSS styled sites into a basic text site that allows for easier navigation or an option to flip to a different style sheet that makes the text on the site itself larger and allows users with poor eye sight to consume your information better.
WHO BENEFITS?
Everyone. It’s really that simple. Those with hearing or vision loss are obviously in the forefront, but they are not just the main benefactors of designing with accessibility in mind. As a designer there are many other benefits.
Reduced Server Load: Your code will be leaner and cleaner which in effect will reduce the need for additional servers and also increasing your download speed.
Search Engine Optimization: This alone could be one of the most important benefits of designing for accessibility. The way you structure your site with a clear hierarchy, the proper naming of ALT and TITLE text, and when you use text instead of images to display important names, you boost your SEO astronomically.
Increased Site Traffic: One of the natural effects of making your site useable by all is that now your site welcomes a wider audience.
Saves You Money and Time: Decreases personnel costs for maintaining the site due to reduced site maintenance in the long term. It also decreases the amount of server space needed and the costs associated with it.
SECTION 508
In 1998, Congress passed an amendment to the Rehabilitation Act.
This act covers three main groups:
1. The visually impaired
2. The hearing impaired
3. Those with physical impairments
This amendment requires that all websites that are created for the United States government, which includes all organizations and businesses which receive any federal funding, including a high percentage of all non-profit organizations and medical and mental healthcare businesses be accessible to those who are visually, audibly, and physically disabled.
This law applies to any and all technology that falls under any government funding, including but not limited to: hardware, software, webpages, copiers, fax machines, telephones, and more. The only exception to this amendment is that a website may get a waiver granted if their audience is under a certain number, and the site owner can provide evidence that there are no users who have or will visit the site who may have disabilities or any kind. This type of waiver is very rare to get.
The penalty for failing to comply with Section 508 is up to $55,000 dollars for the first violation as well as $110,000 per subsequent failures.
DESIGNING FOR THE BLIND
This section refers to those who are deemed legally blind and also those who have been diagnosed as medically blind.
BLIND ISSUES
Users who are blind will always have a hard time with your site if it has:
· Improperly structured HTML and forms
· Poor fallback implementation where there are features that require vision
· Repetitive items that cannot be skipped by screen readers
· Images that have no meaningful alt text
· Labels which are not properly named
SCREEN READERS
In order for the visually impaired to be able to visit and browse your site, they must install a screen reader. A screen reader is an application that reads aloud the text presented by the website.
Screen readers are able to do a few different things including scanning and reading every word on your page, in addition to alt and name tags that are in the HTML. A properly designed accessible site will list all the headers and links to the user, which is why structure is so important. However, there are a few things that screen readers cannot do, such as read text in images, detect navigation, and sometimes have problems reading text based on your CSS.
A few different screen readers that are available are:
· VoiceOver (mac integrated)
· Microsoft Navigator (windows built-in)
· ORCA (unix)
These readers can be costly. JAWS, which is developed and maintained by Microsoft, costs over $800.00.
NVDA
For this report we will be using a free and popular screen reader NVDA, which stands for Non Visual Desktop Access. NVDA is considered one of the top screen readers in the world.
CODING FOR THE BLIND
This section will explore and demonstrate the correct and wrong ways of coding a blind accessible website, and will include the provision information from Section 508 for the methods we are examining.
USING CSS
When designing accessible sites, it is extremely important to keep your HTML files as clean as possible. The usage of internal and inline styles are discouraged, and cause bad interactions with screen readers; external styles are the preferred method. Keep in mind that failing to use external style sheets may cause your site to fail accessibility, and you may be slapped with the aforementioned fines.
One of the biggest problems visually impaired users face is when information is “floated” to the right side of the page using “float:right”. This can cause the screen reader to relay your information out of order instead of the way you intended from left to right. For example:
As you can see the obvious logical order for this site is left to right. However, in the code for this site, the section that is floated right comes before the left side and therefore the screen reader would start on the right side. The solution to this problem and what is considered a “best practice” is to always float everything to the left. This allows for the content to be stacked in the order it was written as opposed to just what is visually seen. If you must use the attribute of float:right, it is imperative that your text be in correct HTML order.
STRUCTURING YOUR SITE
One of the most important parts of designing for accessibility is making sure your HTML and CSS are structured correctly. Screen readers that are setup for the English language will always read from the top of the page to the bottom and left to right. In addition to the overall flow of the page, structuring elements such as header tags, link tags, and image tags must be used and named properly in order for the screen reader to render them correctly to the user.
STRUCTURING HTML
The rule of thumb when structuring your HTML is to keep it as naturally flowing as possible and consider how you would want your user’s eyes to navigate the page. In addition to the flow of your HTML, the foo.html file should contain only HTML unless there are circumstances that prevent it.
HEADING TAGS
When doing research for this paper, the overwhelming response to the importance of using heading tags was astounding. Once a user arrives at your site, they use the screen reader to navigate the headings until they find the section they want to hear. In my tests it was the “H” key with the screen reader NVDA. As an example the screen reader may read aloud the following line by line every time the “H” key was pressed:
“Level 1 Heading: Welcome to my site!”
“Level 2 Heading: Man Gets 1 million dollar bonus”
“Level 2 Heading: How is global warming changing the world”
Once the user has found the heading they would like they simply select that heading, and the content would then be read to them. This type of structure allows the user to skip the content they don’t want to hear. While the majority of sites do use heading tags for the main sections, it is common to use CSS to size the font giving the appearance of a heading to a visual users, while being detrimental to those who depend on a screen reader.
NAVIGATION
When designing accessible navigation, you must provide text links in order for the screen reader to be able to recognize and render it as such. While this may seem limiting since most designers want to use graphics such as sprites, the solution is to use CSS to hide the text, using the display:none or visibility:hidden properties or using text-indent to push the text off the screen. The following are all correct ways to hide text.
In addition to having to provide text links to make your site accessible, you must also offer your users an option to skip any navigation on your site. In SECTION 508 the provision reads as:
1194.22(o) A method shall be provided that permits users to skip repetitive navigation links.
The following is a method that may be skip navigation:
TEXT EQUIVALENTS FOR IMAGES
Section 508: 1194.22(a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content.)[3]
Images are meant to be viewed and some developers overlook the fact that while we can’t help the user visually see the image with their eyes, we can assist in painting a mental image using alt, and longdesc tags. These tags must have meaningful text, and be short but descriptive. Here are a few examples.
Example #1 was coded to display an image properly; however there is no description to let our user know any information about the image. Most screen readers, when they encounter an image with no alt text, will get stuck and sometimes requires the user to completely restart their computer before they are able to use it again.
Example #2 was coded to display an image properly and does include some alt text. However the description is so generic that the information would be of no use to our users who need help mentally seeing the image instead of physically.
Example #3 was coded to display an image properly and includes a meaningful description within the alt tag. This description, while short, gives our visually impaired users a much better experience, and helps them enjoy the content equally. This method should also be applied to images which reside inside an “anchor” tag as seen below.
The alt tag isn’t the only way you can make your images accessible, even though it is the most popular. The “title” and “longdesc” tags are also acceptable, and are also 508 compliant. The title allows you to input a short descriptive title of your image that your visually impaired users will be able to hear. In addition to the alt & title tag is the “longdesc” tag. The “longdesc” tag pulls the description of the image from a separate file or section of another page. In the example below the “longdesc” tag is pointing to another page which gives the description of the seashell the image is showing.
TABLES
When using tables in your site you must always include row and column headers and the use of the “scope” to identify rows and columns. These practices make it much easier for the screen reader to process and deliver the information in a way that makes sense to the user. SECTION 508 has 2 provisions that relate directly to tables:
1194.22(g) Row and column headers shall be identified for data tables.
1194.22(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
Below is an example of an accessible table, which uses the “scope” attribute.
In addition to coding correctly, we must again also offer the user an option to skip the table altogether if they chose to do so. Let’s examine the code:
FORMS
Forms can be one of the most frustrating tasks a disabled user can encounter when they are not properly created. The form not only has to be labeled and the fields named properly, but they must also allow for keyboard navigation. One of the most common problems that make forms unusable by keyboard is JavaScript. If using JavaScript you must be extremely careful or you will disable the form entirely. However the most important part of creating a form is making sure every input you need filled in is labeled and named properly. The easiest way to do this is using the “for” attribute, and making sure the “name” attribute is also added. In the example below we see the inaccessible and accessible way to create a form label.
WAI-ARIA (Web Accessibility Initiative-Accessible Rich Internet Applications)
The most recent development in accessibility is WAI-ARIA. WAI-ARIA allows for disabled users to be able to interact with even the most advanced features of a website by setting roles to different elements on the website. This new feature works by adding meta-data to those element’s HTML tag. Most frameworks such as Google Web Toolkit and JQuery already have ARIA built in.
LANDMARK ROLES
One of the many features of ARIA is the introduction of landmark roles. Landmark roles are used to identify certain features on your site such as navigation and main content. These roles are very helpful in letting the visually impaired jump from each of these landmarks very easily with the press of a button. .
Let’s take a look at how a site might be structured with ARIA landmarks:
An example of coding for an ARIA landmark:
Now that we have covered sectioning off our site, it is just as important to assign other “roles” to different key functions of our site, a key example is buttons. Buttons are interactive controls, and therefore must be focusable. In general buttons are very easy to distinguish by the way they visually appear on the screen. Using ARIA, we can now assign roles to those buttons which will prompt our user that it is indeed a button or call to action. The screen reader will now be able to see the button for what it is, instead of reading it as an image or link.
The example below assumes that you have styled the <span> element to look like a button in your CSS, and that handleBtnClick and handleBtnKeyUp are event handlers that perform the button’s action when clicked or when the spacebar key is pressed.
For more information on ARIA landmarks I suggest checking out: http://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/
CONCLUSION
In closing, I hope this report helps educate and demonstrate on the importance of designing for an accessible web. This vast world of information shouldn’t be limited due to disabilities, and if we as designers take the time to understand the problems they are faced with when they turn on their computers every day, the technologies they are forced to use, and then take the time to learn the techniques needed to make our sites accessible, we can help make a difference in someone’s life.
ADDITIONAL RESOURCES
Author, Multi. Web Accessibility: Web Standards and Regulatory Compliance. Apress, 2006.
Cunningham, Katie. Accessibility Handbook. O’Reilly Media, 2014.
http://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/