You are here: American University Content Publisher Tools Best Practices Accessibility for the Web

Back to top

About Accessibility

Accessibility is the realm of user experience design that addresses discriminatory aspects related to equivalent user experience for people with disabilities, including people with age-related impairments. For the web, accessibility means that people with disabilities can perceive, understand, navigate, and interact with websites and tools, and that they can contribute equally without barriers. The following are some terms you may hear when discussing Accessibility at American University:

Section 508
In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. Section508.gov
Section 504
This section of the Rehabilitation Act of 1973 prohibits federal agencies, programs, or activities from discriminating and requires reasonable accommodation for qualified individuals with disabilities.
WCAG 2.0
Web Content Accessibility Guidelines were set out by the World Wide Web consortium (the governing body of the Web) to define accessibility on the web. Section 508 is the letter of the law, WCAG is the spirit. Additionally, a refresh to Section 508 is in the works which will simply require compliance with WCAG 2.0 Level AA.
ARIA
Accessible Rich Internet Applications are a set of additional attributes which allow conforming technology to better understand how pages and content interact with and relate to each other. For example, ARIA tags provide additional information about how the header of this collapsible relates to its content.
BOIA & WAVE
The Bureau of Internet Accessibility is our current tool for scanning and reporting on the www.american.edu site.
WAVE is a Chrome browser extension you can install that can scan your page directly in the browser and report on issues for remediation.

There are many types of users who are helped through accessibility, including but not limited to:

Visual Disabilities
Blindness, Color blindness, low-visual acuity, etc.
Auditory Disabilities
Deafness, hard of hearing, etc.
Cognitive & Neurological Disabilities
Attention deficit hyperactivity disorder (ADHD), Autism spectrum disorder (ASD), dyslexia, seizure disorders, etc.
Physical Disabilities
Amputation, Arthritis, repetitive stress injury, etc.
Everyone
Accessible content is also highly usable content

For more, see Diversity of Web Users

It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with diverse abilities. Indeed, the UN Convention on the Rights of Persons with Disabilities recognizes access to information and communications technologies, including the Web, as a basic human right.

Accessibility supports social inclusion for people with disabilities as well as others, such as older people, people in rural areas, and people in developing countries.

There is also a strong business case for accessibility. Accessibility overlaps with other best practices such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimization (SEO). Case studies show that accessible websites have better search results, reduced maintenance costs, and increased audience reach, among other benefits. Developing a Web Accessibility Business Case for Your Organization details the social, technical, financial, and legal benefits of web accessibility.

Why: The Case for Web Accessibility

Important Concepts

These three concepts underpin the majority of Accessibility techniques.

Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages and web applications rather than merely to define its presentation or look. Semantic HTML is processed by traditional web browsers as well as by many other user agents.

Wikipedia

Unobtrusive JavaScript is a general approach to the use of JavaScript in web pages. Though the term is not formally defined, its basic principles are generally understood to include: Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation.

Wikipedia

With the adoption of Semantic HTML principles, CSS should be used to handle your presentation (layout, design, style, etc.) of your content instead of trying to use HTML tags to accomplish that.

CSS should either be in a style tag or a separate .css file, do not use inline style attributes on a tag unless absolutely necessary. When using an inline style, do not use it to specify font sizes, margins, or padding as these can cause problems for both Accessibility and Responsiveness.

Techniques: Basic Content

Do not write text in all capitals unless it is an acronym.

Content in all capitals may get read by a screenreader letter by letter.

If you wish to display content in all capitals, apply the class text-uppercase to the element.

Headings

Headings (h1, h2, h3, h4, h5, h6) should be used to structure your page's content. For the general user they help with scanning the page for relevant content as well as chunking the content into easily digestible bites. For the user of Assistive Technology (AT), they provide landmarks that the user can jump between easily while navigating the page.

Headings should be chosen for their semantic, structural significance not for their appearance. For example, you should never go from an h1 to an h4.

Faux Headers

A faux header is a line of text that is styled in such a way as to appear like a header to a sighted user either through bolding, italicizing, or underlining.

Using faux headers deprives the unsighted users of the semantic, structural, and navigational aids that a true heading provides and thus is a violation of WCAG 2.0 and Section 508.

Often times a faux header situation will occur when you're trying to draw attention to a particular sentence. In some cases, a true alert would be a better solution. In others, bolding only keywords in the sentence (as I did in the previous paragraph) achieves the desired emphasis without triggering a faux header violation.

Do not use tables purely for layout purposes. If you are attempting to layout content side-by-side or in columns, there are better, more semantic options available.

Tables should be used only to display truly tabular data. Think along the lines of Microsoft Excel. Can you follow a column header and a row header to arrive at a distinct data point? Then you may use a table.

Tables must be properly configured as well. They must have a summary provided by the summary attribute on the table tag. They must have a clearly defined thead with proper th cells with the scope attribute set. They must have a clearly defined tbody with proper td cells.

A well-formatted table is easy for users of Assistive Technology to navigate.

Unordered Lists (ul)

If the order of elements in a list has no semantic importance, then an unordered list ul should be used. A list should never contain headers or other content that serves to break up the list. If you are using headers to break up one list, there should be multiple lists (i.e. list, header, new list, header, new list, etc.). Assistive Technology reads out that the content is a list and that it contains X number of items. Interspersing headers and other content into the list messes up this data (i.e. it isn't 1 list of 21 items, it's really 3 lists of 6 items with 3 headings).

Ordered Lists (ol)

If the order of elements in a list does have semantic importance, then an ordered list ol should be used. For example, an alphabetical listing should be in an ordered list, or steps in a process should be in an ordered list.

Multi-Column Lists

If you wish to have a list display in multiple columns, utilize the available classes (cols-4-3-2, cols-3, etc.) to achieve this. Do not break the list up into separate lists. For example, if you have one list of 21 items that you wish to appear in 3 columns, make one list with the class cols-3. Do NOT make 3 separate lists.

Definition Lists (dl)

If there is a relationship between elements in the list (such as a glossary page or list of important dates) use a definition list dl.

"Tabular Lists"

As mentioned previously, you shouldn't use tables to achieve a side-by-side layout. If there's a relationship between your left and right columns, you can use a "tabular list" which is a definition list with class tabular: dl class="tabular"

When the principle of Semantic HTML was adopted certain HTML tags that were used to express presentation were deprecated and should no longer be used.

To bold something, you should use the strong tag, not the b tag.

To italicize something you should use the em tag (if the italics if for emphasis) or cite (if the italics is for citation), not the i tag.

To underline something, you should use CSS text-decoration:underline, not the u tag.

To center something, you should use CSS text-align: center, not the center tag.

Contrast

WCAG 2.0 requires that text have a certain contrast ratio with its background.

Normal text (<24px, non-bolded text) must have a contrast ratio of 4.5:1

Large text (18px+ bold, 24px+ non-bolded text) must have a contrast ratio of 7:1

You can check the contrast of your colors at WebAIM's Contrast Checker. Please ensure that you factor any opacity changes you may be applying to your colors before checking them here.

Acceptable Brand Palette Combos

Multiple Signifiers

Color should not be your only signifier of important information. For example, changing text to red in an error state alone is a problem for a color blind person. Adding an additional modification such as size, weight, shape, etc. is required.

Avoid

Wherever possible, avoid using acronyms or abbreviations.

Expand

At a minimum, on first use of an abbreviation you should use it in conjunction with its expanded version. For example, "College of Arts & Sciences (CAS)" or "CAS (College of Arts & Sciences)."

Tag

The most accessible way to handle abbreviation is to tag them with the abbr tag. For example <abbr title="College of Arts & Sciences">CAS</abbr>.

This may not be possible in all cases due to CMS limitations, but at the very least it should be done for common acronyms that have different meanings in American University's context. For example, GPS means one thing to most users, but means Graduate Professional Studies in an American University context.

Techniques: Images

Alternative text for images is a bit of a subjective art. However there are a few definite rules:

  1. Images that are not purely decorative should have an alt attribute that describes the content and function.
  2. Avoid redundancy between alternative text and surrounding content. For example, alternative text should not be redundant with a visible caption or a headline that appears directly before or after it on the page.
  3. Purely decorative images should be implemented via CSS if at all possible. If they must appear in the code, they must have an empty alt attribute: alt=""
  4. Do not use "Photo," "Image," "Icon," or similar words as part of the alternative text. The screenreader already alerts the user that it is a graphic. "Logo" or "Seal" may be acceptable in some instances where the official nature of the document/image needs to be reinforced.
  5. Do not use the title attribute as a substitute for the alt attribute. Screenreaders are not consistent in being able to access this attribute.
  6. Do not get into the weeds on details of the image, but don't be stingy either. A minimum of 8 characters is required and shoot for no more than 140 characters (an original tweet size).

NOTE: Avoid words like "banner" and "ad" in your alternative text and file names as Ad Blocker software may block these entirely which can cause both Usability and Accessibility concerns.

If you are using an image as the only content within a link tag (a), you absolutely must have a non-null alt attribute on your image.

Screenreaders will completely skip a link containing just an image with no alternative text.

If there is text in the image that is not immediately adjacent to the image, the alt attribute must contain all that text.

Only the text that is in the image matters, background content should not be referenced with phrases like "with text overlay reading...". See Image with Text Example Slide. 

When dealing with icons or buttons, function trumps content for the alternative text.

For example, a button with an envelope icon that sends an email should have function-based alternative text (alt="Send Email") not content-based (alt="envelope").

Consider a listing of Social Media icons. You might use the icon of the blog hosting platform as the link to your blog. If you put the content of the image ("WordPress Logo") that doesn't tell the user much about it. If you put the function ("AU Ambassadors Blog") that tells the user so much more.

Techniques: Interactive Content

You are responsible for the accessibility of any content that you embed into the site via an iframe, so embed content wisely.

Visible Content (Videos, Forms, Maps, etc.)

For content that is visible to the average website visitor, you must provide a descriptive title attribute for your iframe and provide fallback content between the iframe open and close tag.

For example:
<iframe title=“Google Maps map of American University Campus” src=“http://maps.google.com”>
<a href=“http://maps.google.com”>View a Google Map of the American University Campus</a>
</iframe>

Hidden Content

For hidden content, such as Analytics and other tracking codes, there should be a title attribute and fallback content as well, but it should indicate that this information can safely be ignored.

For example:
<iframe title=“Ignore: Google Analytics” src=“http://google-analytics.com”>
Ignore: Google Analytics
</iframe>

Forms are where it is incredibly important to have proper Accessibility. At a bare minimum, the following items are required for form accessibility:

  1. The form must have a defined action
  2. The form must have an input or button with type set to submit
  3. The form must have clearly defined and related labels (using the for and id attributes) for all form inputs. NOTE: placeholder is not an acceptable Accessibility replacement for label
  4. Any JavaScript bound to the form should account for keyboard only users (i.e. bind to form submit, not to click of the submit button, etc.)

For further assistance with forms, please contact OIT via the Help Desk.

In addition to the iframe title and fallback content mentioned above, videos should be captioned.

A captioning policy and process is being worked on at the University level. Stay tuned for more details.

When you need to provide an accommodation notice, use one such as this: "To request accommodations for persons with special needs, contact (name, department) at (phone and email), allowing sufficient time to make arrangements."

For more information on making non-HTML documents accessible, please check out Section508.gov.

For users with access to Adobe Acrobat DC, you can view a training on PDF accessibility at Lynda.com (AU Login Required).

Tools and Services

http://wave.webaim.org/extension/ for Chrome

Activate while on the page and flags will pop up. Use on www pages not cms as there may be errors with cms due to access issues

  • Red Alerts: Must fix if within your purview
  • Yellow Alerts: Should fix if possible

Utilize the "No Styles" toggle if you are having trouble locating an error.

If you know the colors you wish to check, you can use their web tool at http://webaim.org/resources/contrastchecker/

You can also scan your site with options within the WAVE toolbar mentioned earlier.