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)
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.
- For new sites, once the Web Development Center 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.
- To maintain the accessibility of new and old sites, Compliance Sheriff scans must be viewed on a quarterly basis. Identified issues require remediation.
- 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. The W3C's WAVE tool must be ran before the web pages is published.
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.
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.
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 testing with Job Access with Speech (JAWS) 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.
Rules for Alternative Text
- Should provide a short description of what is in the image. Example: alt="Students shaking hands."
- If the image contains text, the alt text should contain the same text.
- If the image is within a link, it should provide information about the page it is linking too. Example alt="CSULB Home page."
- Alt text should not include "image of" or "link."
- Alt text should be not more than 80 characters.
To learn more about alt text, see WebAIM’s Alternative Text Tutorial.
Text Only Images
When images with text have more than 80 - 150 characters, the alt text must provide the main topic of the text and then the rest of the text must be added to the content below the image.
To learn more about images with text, see Diagram Center's Specific Guidelines – Text Only Images
Charts and Graphs
Charts and Graphs provide a lot of information that need to be conveyed to visually impaired users. The alt text must contain what type of chart it is and what it is about (See Example). The information should be in placed in a table or formatted for easy reading below the chart or graph.
Example: alt="Bar chart comparing sales of iPhones vs Android from 2015 to 2018. See table below"
To learn more about alt text for Charts and Graphs, see Diagram Center's Specific Guidelines – Graphs
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.
- H1 Element: 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.
- 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.
- H3 Elements: should markup sub-section of content within new section of content.
- Heading 1
- Heading 2
- Heading 3
- Heading 2
- Heading 2
- Heading 3
- Heading 3
- Heading 2
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.
Content that contains associated information like a set of policies or instructions should not be placed in a paragraph, but in an unordered or ordered list instead. This will make it easier for all users to read and understand. For screen reader users, the screen reader will let them know how many items are in the list.
Supplies need for painting class:
- Water Colors
- Box for supplies
It is important that the color contrast between the font color and background color is sufficient, so people who are color blind or have low vision can read the content of the web page.
A color contrast ratio of 4.5:1 is the minimum for font below 1.5ems or 24px and for font above, it is 3:1.
To test the color contrast, download the Colour Contrast Analyzer tool, by The Paciello Group.
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.
- Open the webpage in a browser.
- Use the tab key to tab through the active elements on the page.
- Ensure keyboard focus moves to the top navigation and any active elements in the heading section and then to the secondary navigation if any.
- Next it should move to the left navigation and then into the main content.
- In the main content, the order should be logical also.
- 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.
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.
Data tables created in the Drupal editor have the semantic code added, so only table properties need to be selected.
- Headers: Select "First Row" from the drop down. Note: Only complex tables will use table heading in the first row and column.
- 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.
|Heading Col 1||Heading Col 2|
|Data Table Cell 1||Data Table Cell 2|
|Data Table Cell 3||Data Table Cell 4|
Note: TH elements cannot be blank, then must contain data or be changed to a TD elements.