You are here

Web Accessibility

Creating accessible web pages may seem challenging at first, but as developers and content editors become familiar with testing pages, the more it becomes a part of the process. At CSULB, we test with standards and guidelines set up by the Chancellors Office. They follow the Web Content Accessibility Guidelines (WCAG) 2.0 level AA created by the W3Cs Web Accessibility Initiative.  

The Drupal Template and the new University Template have been evaluated for accessibility, but new content that is added to the templates will need automatic and manual testing.  

For an in-depth tutorial see, Introduction to Web Accessibility, by Web Accessibility in Mind (WebAIM)

Responsibilities 

Depending on one's position, different responsibilities will apply to website accessibility.

 

Web Administrators and Web Developers

Web Administrators and Web Developers are responsible for ensuring the websites they maintain are accessible. 

  1. For new sites, once the Office of Marketing and Communication has reviewed and approved the site an accessibility review will be done, including a Compliance Sheriff scan. If there are any issues found, they must be fixed before the site can go live.
  2. To maintain the accessibility of new and old sites, Compliance Sheriff scans must be viewed on a quarterly basis. Identified issues require remediation.
  3. The Web Accessibility Coordinator will run a Google Analytics report for the top 25 pages of each college, division and department website. The pages on the report will need to be manually tested. This report will coincide with the quarterly Compliance Sheriff scan.

Content Editors and Content Approvers

Content Editors and Content Approvers are responsible for ensuring new and updated Drupal pages are tested for accessibility.  Compliance Deputy or the W3C's WAVE tool must be ran before the web pages is published. 

Automated Testing

Whether a page is new or updated, an automated accessibility test will need to be run on the page. Automated tools are in-browser or online services that help determine if the web page meet certain guidelines.   

Automated tools are good for finding coding issues, missing alt attributes, link issues and contrast issues. However, automated testing tools only find 25% of accessibility issues the reminder need to be manually assessed. 

 

Compliance Deputy

Compliance Deputy (CD) is the browser-based tool CSULB uses.  CD is an on-demand browser-based solution that allows developers and content providers to test and repair content. It leverages the CSU checkpoints and rules designed to test pages.  CD can be added to the Chrome browser through the Chrome Web Store. For installation information, see Compliance Deputy Install for Chrome (PDF)

WAVE Accessibility Evaluation Tool

The WAVE tool by Web Accessibility in Mind (WebAIM) is also an automated accessibility tool. WAVE helps web developers make their web content more accessible. The WAVE tool can be added as a Chrome extension through the Web Store. The extension can check password-protected, dynamically generated, or sensitive web pages. The WAVE extension evaluates the rendered version of your page, locally displayed styles and dynamically generated content from scripts.

Note: Once the WAVE tool has run, it is recommended users uncheck the HTML5 and ARIA checkbox, so it is easier to see the other details on the page.  The templates use a lot of HTML5 and ARIA and it can be confusing to see all the icons. 

If you don’t wish to download the WAVE extension, please visit the online test page.

Manual Testing

Most accessibility issues are found by doing manual testing. Manual testing includes, but not limited to how a screen reader renders the page, navigating by keyboard, dynamic content updates, background image with text etc.

Manual testing also involves using Job Access with Speech (JAWS) in Internet Explorer version 11 (IE 11)  to make sure screen reader users have access to the content of a site and are provided the same information as sighted users.  See Using JAWS to Evaluate Web Accessibility for information on how to get started with JAWS. 

 

Images Alternative Text

Alternative text or alt text is what provides screen reader users with a description of an image. If there is no alt text on the image tag, the screen reader will read the URL of the image, which may be confusing to the screen reader.

Even though the automatic accessibility tool will check to see if an image has alt text, it is up to the developer or content editor to make sure the alt attribute is meaningful to screen reader users. 

  1. Should provide a short description of what is in the image. Example: alt="Students shaking hands."
  2. If the image contains text, the alt text should contain the same text.
  3. If the image is within a link, it should provide information about the page it is linking too. Example alt="CSULB Home page."
  4. Alt text should not include "image of" or "link."
  5. Alt text should be not more than 80 characters.

To learn more about alt text, see WebAIM’s Alternative Text Tutorial.

Keyboard Accessibility

It is important that all active elements (e.g. links, buttons and form fields) receive keyboard focus and in a logical order. Keyboard focus should be visually indicated when the active element receives focus.

Receiving Keyboard Focus and Logical Order

If using sematic HTML to create links, buttons and form fields, keyboard focus will automatically move to these active elements. It is built into the browser and developers do not need to add anything to these elements.  However, keyboard focus still needs to be tested.

Logical order is making sure the keyboard focus moves to active elements from top to bottom, left to right. Keyboard focus should follow the reading order on the page. 

Testing

Since most assistive technology uses IE 11, it is best to test the order in that browser.

  1. Open the webpage in IE 11. Make sure to uses a fresh browser, so if IE 11 is open, close it and then re-open it.
  2. Use the tab key to tab through the active elements on the page.
  3. Ensure keyboard focus moves to the top navigation and any active elements in the heading section and then to the secondary navigation if any.
  4. Next it should move to the left navigation and then into the main content.
  5. In the main content, the order should be logical also.
  6. Lastly, focus should move to the footer.

Note: To tab backwards use Shift + Tab. To move through drop-down menus, use the arrow keys or the tab key. 

Visual Keyboard Focus

When tabbing through the page, ensure when active elements receive keyboard focus there is an outline, underline or color change to let keyboard-only users know where on the web page they are.

Both the Drupal and the University Template active elements indicate they have received focus. If navigating through a page and the keyboard focus is missing, ensure that it was not over-written in the CSS. 

To learn more about Keyboard Accessibility, see WebAIM’s Keyboard Accessibility Tutorial.

Links

When adding links to a web page the link name should contain descriptive words and not the actual URL. This is so screen reader users will not hear the full URL, which could be quite lengthy and confusing.   The link name should indicate to all user the purpose of the link.  

Rules for Links

  • Links should only contain a few words. Full sentences should not be linked.
  • "Click Here” should never be used for a link.  
  • "Read More" can be used sparingly, but only if it is within the associated paragraph.  Some pages many need to use many "Read More".  If that is the case, contact the Web Accessibility Coordinator.

Headings

Heading elements like H1 and H2 help screen reader user navigate the web pages and lets them know the hierarchy of the content.

Heading elements also help sighted users by breaking up content in to categories that they can easily scan.

It is important to use Heading elements correctly and not for styling content. 

  1. There should only be one H1 element on a page.  The Drupal CMS will automatically create the H1 element. For the University Template, developers will have to make sure it has been added.
  2. H2 elements should markup new section of content. This lets both sighted users and screen reader users know there is a new section of content.
  3. H3 elements should markup sub-section of content within that new section of content. 

Structure showing heading elements H1 with nested H2, H3's and H4

Color Contrast

It is important that the contrast between the background color and the font color is sufficient, so people who are color blind or have low vision can read the content of the web page.  A hexadecimal contrast of 4.5:1 is the minimum for font below 14px.

To test the color contrast, download the Color Contrast Analyzer tool, by The Paciello Group. 

Color Contrast Examples

Data Tables

Data tables are not to be used for formatting content, but only to display tabular information in rows and columns. Most Data Tables are simple and just need a little bit of code to help screen reader user navigate the table. For more complex data tables, please contact the Web Accessibility Coordinator.

Drupal CMS

Data tables created in the Drupal editor have the semantic code added, so only table properties need to be selected.  

Table Properties:

  1. Headers: Select "Both" from the drop down
  2. Captions: A caption can be added, but it is not necessary. If adding, make sure it is short and describes the content of the table.   

Non - Drupal CMS

When creating data tables in the new university template, it is important to remember to include semantic table markup. Captions can also be added to help screen reader users know what the content of the data table pertains too.  

Table Headings and Scope

Like the Drupal template, the first row and column should be a marked up with "TH" elements. The first column would have scope="row" added for each "TH" and each "TH" in the first row would have scope="col" added.

Note: TH elements cannot be blank, then must contain data or be changed to a TD elements. 

Web Accessibility Exemptions

In the event web content cannot meet these standards due to their inherent nature or technology limitations, a request for web accessibility exemption can be made. Please see the Web and Document Accessibility Exemption Request Form (PDF).