Digital Accessibility Guide

Accessibility is for everyone

Digital accessibility techniques remove barriers between your visitors and your content. People with disabilities such as visual impairments, hearing loss, mobility issues and cognitive deficits may be among your readers. But accessibility measures also assist users with temporary disabilities or those multi-tasking or distracted—all common ways of living life. Accessibility is about supporting all users, no matter the technology they are using.

UNC is committed to creating an accessible web presence, and we need you to do your part. If you own, operate, or contribute to a website, then you need to ensure web accessibility (often abbreviated a11y). This page provides highlights with resources for more learning.

Learn more about the Digital Access Initiative at UNC. The offices of Accessibility Resources & Service and the Equal Opportunity and Compliance Office offer additional resources for the Carolina community.

Web Content Accessibility Guidelines
The regulations derive from ADA Title III and the Rehabilitation Act of 1973 Sections 504 & 508. The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) maintains standards for verifying elements called the Web Content Accessibility Guidelines, or WCAG 2.1 (updated June 2018); we follow level AA. (Most documentation found on WCAG refers to version 2.0, which is suitable for training on techniques.) WCAG is a globally recognized standard.

Accessibility is a process, not a project

Digital accessibility is a series of processes, not a one-time project; therefore it requires an ongoing commitment. It means auditing existing sites and fixing them page by page as well as developing new sites with accessibility in mind from the start. The solutions include a combination of automated tests and manual remediation. No tools will automatically make your site accessible. Improving accessibility also improves the usability of your publications.

Core skills for making content accessible

Heading levels <h1> to <h6>

  • Use section headings to communicate the organization of the page’s content
  • Follow the structure of the content: Start with h2, then h3, h4, and so on, without skipping any levels
  • h1 is reserved for page title only
  • Do not choose a header for its appearance; instead, use the proper h-level and ask your developer to adjust relative sizes of headers in CSS

DON’T

<h1>Using Your Camera</h1>
<h3>Setting Manual Exposure</h3> <!-- Skips a level -->
   <p>Text here ...</p>
   <h4>Set the ISO</h4>
<h3>Setting Automatic Exposure</h3> 

DO

<h1>Using Your Camera</h1>
  <h2>Setting Manual Exposure</h2> <!-- Doesn't skip -->
     <p>Text here ...</p>
     <h3>Set the ISO</h3>
  <h2>Setting Automatic Exposure</h2> 

DON’T

<p style="font-size: 200%;">Setting Manual Exposure</p> <!-- Misuses styles -->
<p style="font-size: 150%;">Set the ISO</p>
<p style="font-size: 125%;">Pushing</p> 

DO

<h2>Setting Manual Exposure</h2> <!-- Uses headings -->
  <h3>Set the ISO</h3>
   <h4>Pushing</h4>

Image descriptions

  • All photos, charts, graphics, etc. need text alternatives, employed as the alt attribute on the img element in HTML and known more commonly as alt text
  • Essential for sighted users who disable images; essential for screen readers
  • Describe the photo concisely in a manner that keys on the substance of its message
  • Decorative images need an empty alt attribute (two quotes with nothing between) so that screen readers overlook them: alt=""
  • Charts, graphs, and infographics need specific alt text that explains all the information pictured, not just a broad term like “bar chart of growth, 2000-2010”

EXAMPLE IN HTML

Image with substance gets a full description:

Workers disassemble the Zeiss projector in the Morehead Planetarium for removal at U-N-C Chapel Hill

<img alt="Workers disassemble the Zeiss projector in the Morehead Planetarium for removal at U-N-C Chapel Hill">
Image for decoration gets empty alt text:

<img alt="">

EXAMPLE IN WORDPRESS

wordpress dialog box for image with alt text field filled in

Color

  • Ensure color contrast minimums are met for foreground and background combinations
    • WCAG requires a 4.5:1 ratio or higher for smaller fonts and 3:1 for larger
    • UNC identity color palette provides a guide for recommended UNC colors
      • Web Carolina Blue paired with white passes only at larger sizes, and Link Blue paired with white passes at smaller sizes
    • Use online tools that check color pairings to meet the contrast ratios
  • Avoid color as a sole means of conveying information such as green for go and red for stop without text labels or universally understood symbols

Web Carolina Blue
Hex #4B9CD3
RGB 75, 156, 211

Link Blue
Hex #007FAE
RGB 0, 127, 174

Athletics Navy
Hex #13294B
RGB 19, 41, 75

Light Gray
Hex #E1E1E1
RGB 225, 225, 225

Dark Gray
Hex #767676
RGB 118, 118, 118

Black
Hex #151515
RGB 21, 21, 21

Content

  • To create proper pronunciation in screen readers, specify a language on the html element, e.g., <html lang="en">; also markup foreign phrases, e.g., <span lang="fr">Je ne sais quoi</span>
  • Audit your content for clarity and ease of readability; state ideas in plain language
  • Use terms your audience is familiar with, or provide definitions
  • Use proper headings to help users scan the text for the page’s structure
  • Guide users through any tasks, providing instructions where they may be helpful
  • Images should complement the page content
  • Because PDFs, Word and PowerPoint files add complexity over text files to people who use assistive technologies, remove them where possible, or provide a web HTML version first and the downloadable versions as alternatives
    • These docs must also be tested and fixed to meet WCAG (read PDF section below)

Links

  • Write links descriptive of the destination
  • Each link should make sense if read alone; rewrite to avoid ambiguous text such as ‘visit this page’ or ‘click here’
  • Use underlining or other styling to make a clear distinction between links and regular text

DON’T

To view more case studies, click here.
Learn more about our board of directors here.
Download our guide to selecting a keyboard at http://ergonomically-inclined.org/kb/.

DO

View more case studies.
Learn more about our board of directors.
Download our guide to selecting a keyboard.

Lists

  • Use built-in tool to create bulleted and numbered lists (or manually write HTML using <ul> and <ol> elements)
  • Avoid asterisks, hyphens, or other symbols as bullets (unless they are created by the built-in tool)
  • Avoid typing numerals manually
  • Avoid tabbing or spacing to create columns

TO GENERATE THIS

  • One idea
  • A related idea
  • Another related idea

DON’T

   - One idea
   - A related idea
   - Another related idea

DO

<ul>
   <li>One idea</li>
   <li>A related idea</li>
   <li>Another related idea</li>
</ul>

TO GENERATE THIS

  1. One step
  2. The next step
  3. A third step in the order

DON’T

   1. One step
   2. The next step
   3. A third step in the order

DO

<ol>
   <li>One step</li>
   <li>The next step</li>
   <li>A third step in the order</li>
</ol>

Tables

  • Tables should be used to organize tabular data, not for positioning items in a layout
  • The markup (HTML code) for a table is always based on rows, never columns
  • Use table headers (the th element instead of td) on each row and column header

TO GENERATE THIS

Name Position
Chris Catcher
Jamie Shortstop

DON’T

<table>
 <tr>
  <td style="font-weight: bold">Name</td>
  <td style="font-weight: bold">Position</td>
 </tr>
 <tr>
  <td>Chris</td>
  <td>Catcher</td>
 </tr>
 <tr>
  <td>Jamie</td>
  <td>Shortstop</td>
 </tr> 
</table>

DO

<table>
 <tr>
  <th>Name</th>
  <th>Position</th>
</tr>
  ...

Note: Additional CSS may be required

Forms

  • Ensure that every form element (text field, checkbox, dropdown list, etc.) has a clear text label
  • Make sure that label is associated to the correct form element using the <label for=”id”> element
  • An example of an <input> element with a good, descriptive <label>:
<label for="username">Name:</label>
<input id="username" type="text" name="textfield" />
  • Notice that the ‘for’ attribute is important because it links the <label> element to the appropriate <input> element
  • Pre-filled text inside form fields should enhance understanding, not replace the directions
  • Follow the code examples at Teach Access for Labeling Form Controls and Interactive Elements

Docs published to the web or shared with the public

Word

  • Run Word’s Accessibility Checker tool and correct the suggested problems
  • Use preset headings and paragraph styles to structure the document, or save your own styles (refer to image below)
  • Add alt text descriptions to images, charts, clipart, and any other embedded element
  • Follow web practices for links
  • When using tables, build them with the application’s tool, avoiding tabbing to make columns, and keep tables simple (no nesting)
  • Use built-in tool to create bullet and numbered lists
  • Avoid floating objects by placing elements inline with text when possible
  • Fill in document properties with title, subject, and author (title is essential)

The Styles Pane in Microsoft Word

PDF

  • Optimize the original source document (e.g. Word or InDesign), if available
    • Use styles (e.g. in Word) to create headings, not by changing the font
    • Make ordered or unordered lists using the given tool, not with hyphens and indents
    • Designate table headers in columns and/or rows
    • Add concise alt text on photos and graphics
    • Check color combinations for proper contrast, just like on your web pages
    • Save as a tagged PDF from Word, PowerPoint, InDesign, or other application
  • Optimize the PDF in Acrobat Pro (always)
    • Never post a scanned document as this is an image with no selectable text
      • If this is all you have, convert it to text in Acrobat or recreate it in a word or design program
    • Run the built-in Accessibility Checker (this provides a report to guide you that requires several manual fixes); some of the key areas:
      • Set the document language
      • Add a title and ensure the title rather than the file name is displayed
      • Activate and/or add tags, correct tags and delete empty tags
      • Fine-tune the reading order
      • Set the tab order to “use document structure”

PowerPoint

  • Start with one of the built-in templates rather than making your own
  • Add alt text descriptions to images, charts, clipart, and any other embedded element
  • Name your links with the destination clearly stated
  • When using tables, build them with the program’s tool, avoiding tabbing to make columns, and keep tables simple (no nesting)
  • Fill in document properties with title, subject, and author (title is essential)
  • Ensure each slide has a unique title with substance
  • Check the slide reading order using the selection pane and re-order elements as you intend it to be read

Audio/video media

  • Video: Provide synchronized captions of all dialogue and important sounds such as [doorbell], [laughter], [applause] REQUIRED FOR ALL PRE-RECORDED VIDEO FILES
    • In YouTube, if you have the script typed, you can upload and YouTube will automatically match up the text and create the captions; if the sync isn’t perfect, you can tweak it using the built-in tools
    • Or, you can use the embedded auto-generated transcript—better yet, download it, edit to your liking, and resubmit it to YouTube
    • Also provide a text transcript adjacent to the video player or a link to another accessible web page
  • Audio such as podcasts: Provide text transcript REQUIRED FOR ALL AUDIO FILES
    • This can be adjacent to the audio player or a link to another accessible web page

Automated testing tools

Online tools scan your web pages and report errors. You will need to make manual corrections.

  • By using more than one tool below, you will learn what the evaluations mean
  • Some require changes to markup, style sheets, content—or all three

Sitewide basis

Per-page basis

An accessibility report from Chrome Audit (using DevTools), showing a score of 81 and a series of measures one can take to correct code

Color contrast tools

Manual testing methods

Only a subset of accessibility issues can be automatically detected so manual testing is also encouraged. If you are responsible for handling the code, test these areas to increase the chances of finding accessibility issues early:

  1. Using just the keyboard, try using the tab key to navigate through the page; you should be able to tell where you are at all times
    1. Use the tab key to jump to items with focus (links, forms, dynamic content), the enter/return key to activate links, forms, or buttons, arrow keys for navigating between items in lists or tabs, and the space bar to select buttons and check boxes
    2. Are any elements out of the reading order? Missing? Trapped without the mouse?
    3. Are the items receiving focus styled prominently (and not hidden)?
  2. Run screen reader software to find roadblocks: Try NVDA or Narrator for Windows; VoiceOver on macOS; ChromeVox browser extension
    1. Start small with the default settings as this too can take experience to become familiar
    2. All the better to locate a dedicated screen reader user to analyze your site
  3. Disable CSS with browser dev tools or the Web Developer extension to see the page stripped down and look for any elements out of order; Web Developer is recommended for many other tests too such as outlining headings and tables and displaying alt attributes on images to name just a few
  4. Examine pages with a vision impairment simulator (e.g. NoCoffee or ChromeLens)
  5. Review video and audio for captions and transcripts

Accessible web development resources

Training and tutorials

Written for the UNC Digital Access Initiative by Phil Daquila, ITS Digital Services