Drupal page accessibility for site editors

TOC


Checking your Drupal page for accessibility:

  • To test your Drupal 10 page for accessibility, first get the WAVE extension for your browser. It’s available for: Chrome, Firefox, and Edge. WAVE powers Ohio State’s PopeTech accessibility report generator. With the browser extension you’ll be able to test a page with one-click.
  • To start checking a page with WAVE, go to URL of the page in a browser where you’re not logged. If you use WAVE while you’re logged into Drupal, you may get false positives related to the administrative interface. You might choose to edit the page in one browser while testing it with WAVE in another.
  • Press the WAVE button and start reviewing the results.
  • Press the Details tab to see what errors and alerts were found. Errors tend to be more serious, objective problems, while alerts may be more subjective. WAVE will also let you know if your page has Contrast Errors.
  • Click on an error icon and the click ‘Reference’ to learn more about the error and how to fix it. WAVE will tell you why the error matters and about the algorithm it used to find it. Occasionally you may notice an alert is actually a false positive.
  • To actually fix an error, determine if the error in an editable area of your Drupal page. Content coming after the page’s primary heading H1 may be in the editable area. If the error isn’t in the editable area, but is in the frame around it (the website theme), contact your web developer or your helpdesk for web update requests.
  • Log into to Drupal in another browser to begin fixing the error. Note the location where the error is happening.

Common types of WAVE errors that can be fixed in the editable area of a Drupal page:

  • Skipped heading level alerts – to fix the heading structure you’ll need to select the headings in the Drupal editor where a level is skipped and change them to the appropriate level to nest directly under the next highest level. WAVE has a Structure tab that can show you the next highest level in the headings structure so you’ll know which to change the skipped ones to.
  • Images missing alt text – click on the image and enter alt text description related for the purpose of the image.
  • Empty headings – empty headings (with no text in them) sometimes are accidentally used as a spacer between paragraphs. To fix, backspace and delete where the empty heading is or select and delete it. If you still want the space you could select the empty heading and change it to a normal paragraph in the Drupal editor.
  • Empty links – Sometimes a graphic or icon will be used as a link but have no accessible name (no actual link text or alt tag). When that happens, it’s known as an ‘empty link’. To fix an empty link, give it’s image some alt text related to the purpose of the link or include link text. You may need to switch to the source code view in the Drupal editor to find where to insert the link text in the <a> tag. Insert it between the opening and closing parts of the <a> tag.

If you have questions about WAVE, check their frequently asked questions help page.

Test of changing the role of a span in a menu

This is a test of changing the role of a span to fix an accessiblity issue.

Creating link text intended for screen reader users that is hidden visually

TOC

In some cases, developers may want to create links that are only intended for screen reader users, that are hidden visually. There are two ways to create visually hidden links:

  • The aria-label method
  • The clip method

One case where you might want to have visually hidden links is the case of social media icons. For example, visually you might want to show a Facebook logo for the link, but screen reader users you would spell out the word ‘Facebook’ in the link. So, it would appear as a Facebook logo button, but have an accessible name of ‘Facebook’.

The aria-label method

Aria-label is the attribute that can change the accessible name of a link. In this method, a CSS class is placed in the <a> tag to visually show the Facebook icon, like class=”fb”. Then the aria-label attribute is used in the <a> tag to provide an accessible name. Without aria-label in it, it would be an empty link.  
Aria-label code example:

  <a href="https://www.facebook.com/stateuniversity"  class="fb" aria-label="State University Facebook  page"></a>
  

The clip method

In the clip method, the text that’s desired to be visually hidden is wrapped in a <span> and given a CSS class, like: class=”visually hidden”. Then in that CSS class definition, the text is thrown off-screen, so it’s not seen visually, but remains available for screen reader users. It’s called the clip method because it uses the clip CSS property to redefine the visible portion of the link element and totally clip it from being seen.
Clip method code example:

  <a href="https://www.facebook.com/stateuniversity"  class="facebook_icon">
<span class="visually-hidden">State University Facebook page</span>
</a>

Some CSS for the code example:

  <style> …
.visually-hidden {
border: 0;    clip: rect(0 0 0 0);
height: 1px;    margin: -1px;
overflow: hidden;    padding: 0;
position: absolute;   width: 1px;
}
</style>

Updated clip method CSS

The MDN docs say that the clip CSS property is now deprecated. Here is the CSS updated to use the clip-path method:

  <style> …
.visually-hidden {
border: 0;    clip-path: rect(0 0 0 0);
height: 1px;    margin: -1px;
overflow: hidden;    padding: 0;
position: absolute;   width: 1px;
}
</style>

The clip-path property can also clip with different shapes, other than a rectangle, like: circle, ellipse, and polygon.


 

Resources about creating visually hidden links:

The trouble with table-based layouts

HTML tables aren’t a good choice to use to create columns or layouts in a webpage because they aren’t as responsive to small screens and can cause confusion to screen reader users. Back in the late 1990s a lot of designers used tables for visual layout, but this was later found to be a bad practice because fixed-width table-based layouts didn’t adaptive well to different-sized screens. This layout practice used the HTML <table> element for a use that it wasn’t semantically intended. HTML tables were designed for data grids, from the perspective of semantic structure, so it is better to use them only for that purpose.

How developers can ensure layout tables don’t cause problems for assistive technology

Web developers should take steps to ensure layout tables don’t cause problems for screen reader users. If an HTML table must be used for a layout, the developer should add the role=”presentation” attribute to the <table> element so it’s not confused with a data table. Role=”presentation” tells the screen reader to ignore the semantic table markup and treat it as normal text. The web developer also should not include any of the header markup for data tables in a purely visual layout table. These data table header markup tags to avoid are:

  • The <caption> element
  • The <summary> attribute
  • The <th> element
  • The scope attribute (that goes in a <th> tag)
  • The headers attribute (that goes in a <td> table cell tag)

If data table markup tags are used in a purely visual layout table, screen reader users might expect the table to represent tabular data leading to confusion or a poor user experience. So, if a purely visual layout table must be used the developer should ensure that ARIA is used to make it look like normal text to screen readers. Any purely decorative images used in the table so be marked with null alt text (alt=” “) or hidden from readers with aria-hidden=”true”. Back in the late 1990s, web designers used to use tools like Macromedia Fireworks to slice up webpage visual mockups into layout tables and many time these tables would include a bunch of purely decorative images.

An easy way to avoid the troubles with layout tables is to avoid using them at all. For the modern web CSS (cascading style sheets) is a more robust way to design visual layouts. Once web developers realized web sites would be viewed on devices of many different screen sizes, they began using CSS to create columns, float content, and adapt to different viewport widths. The latest Web Accessibility Guidelines (WCAG 2.1) say that websites should be responsive and including layout tables would likely work against that. According to WCAG guidelines, tables should reflow to fill most of the width of the viewport, without causing any horizontal viewport overflow. On smaller screens it becomes more difficult avoid horizontal scrolling (horizontal overflow).  The WCAG SC that is related to tables and horizontal viewport overflow is 1.4.10 Reflow. This success criterion requires that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for vertical scrolling content at a width of 320 CSS pixels.

How content authors can avoid using tables for layout

As a content author, might craft your blog posts in MS Word documents and you might desire to create a visually interesting layouts using tables in Word. But doing so will introduce some of the same accessibility problems as with using HTML tables for layout in a webpage.  It’s best to paste your content into WordPress blog posts as plain text without MS Word formatting so the conversion to HTML will be more semantically correct, free from accessibility problems. Pasting a table-based visual layout from a Word doc should be avoided because it can introduce accessibility problems into a blog post and lead to poor user experiences for both visual and screen reader users.  Tables aren’t really a valid layout technique in Word documents. They are meant for tabular date (data grids). When publicly shared on the web at public universities, Word docs (and PDFs) are expected to follow WCAG guidelines. So, it’s best to follow accessibility best practices even in our Word documents.

WordPress blog sites may or may not include a table tool in the rich text editor for posts. If your WordPress blog does include a table tool, be sure to use it responsibly. Avoid using the table tool for layout tables unless you have the HTML expertise to markup the table so it doesn’t cause problems for assistive technology. If your blog includes a table tool, it’s best to stick to using it just for data tables. You can ask your department’s web developer to check your data table for accessible markup. It’s possible for rich text editors to create simple accessible data tables but when you get into more complex data tables you’ll have to go to the code view to insert the correct accessible markup. Some more advance table markup that might not be in your rich text editor’s table tool may include:

  • Ability to add the scope attribute (that goes in a <th> tag)
  • Ability to add the headers attribute (that goes in a <td> table cell tag)

Once you get into creating more complex data tables you should probably work with your department’s web developer to make them accessible.  For accessible presentation in websites, sometimes it’s better to split a complex table into two or more simple tables. This makes the data tables easier to understand to screen reader users a more adaptable to different screen sizes (more responsive).

Opening a link in a new window or tab

I tend to like opening links to external websites in a new window with target=_blank. Below is an example of the code I use to make a link like that more accessible. WCAG guidelines say we should warn a screen reader user when a link is going to open in a new window, so I do that with an aria-label attribute in the a tag. Using an aria-label attribute is a way to override the standard accessible name of the link and provide more context for screen reader users.

Example of a link with an aria-label attribute in the a tag


Videos can be hosted in MediaSite

Videos can be hosted in MediaSite

Actually, the best practice for links that open in a new window is to provide both visual and verbal indication. For sighted users an external link icon appended at the end of the link could be used. See this article about opening links in new windows article from the University of California Berkeley for more information about best practices. WCAG guidelines only recommend opening links in new windows in a few special situations.

Complex images and alt text descriptions

Complex images like charts & graphs must be briefly described using basic alt text and must have a more complete long description elsewhere in the page. The long description should be available to both sighted and screen-reader users and be programmatically associated with the image.

The figure / figcaption method:

One of the limitations of basic alt text is that it’s meant to be brief, no more than around 150 characters. So you shouldn’t try to use an alt attribute in an image for the long description. Instead, a good way to add a programmatically associated long description is the use the figure / figcaption method. In this method the figure tag wraps the whole image and long description code. Then the figcaption tag is used to wrap the long description text. This can be normal HTML text that’s available to both sighted and screen reader users. Inspect the code of this preformatted example to see how the figcaption tag is used house a long description.

Pie chart showing factors affecting credit scores. See table next to this image for the data.

Factors in Your Credit Score

Payment History (35%) 35%
Outstanding Debt (30%) 30%
Credit History (15%) 15%
Pursuit of New Credit (10%) 10%
Types of Credit in Use (10%) 10%

The aria-describedby method:

You can also use the aria-describedby attribute added to an image to point to the id of a long description. For example, you could point to the id of a div wrapping a long description like:

    Pie chart showing factors affecting credit scores. See table next to this image for the data.

    

Factors in Your Credit Score

Payment History (35%) 35%
Outstanding Debt (30%) 30%
Credit History (15%) 15%
Pursuit of New Credit (10%) 10%
Types of Credit in Use (10%) 10%

Inspect the code of this preformatted example to see how aria-describedby works. In this example, the table within the wrapper div describes the segments of the pie chart. It wouldn’t be possible to descibe all those segments in basic alt text.

The web accessibility guideline SC related complex images is 1.1.1 Non-text Content (Level A). The W3C WAI has a tutorial with more information about handling complex images. Most universities are striving to meet WCAG level AA conformance. Of the three levels of WCAG conformance, level A is the most important to achieve and level AAA is nice to have but not mandatory. So level AA is a middle ground that most universities and government agencies strive to achieve. Ohio State’s information about minimum web accessibility standards can be found in the Digital Accessibility Center’s website.

Comparing screen readers: VoiceOver and NVDA

VoiceOver for Mac and NVDA for Windows are two popular screen readers helping users with visual disabliites navigate websites. They share some similarities and have some differences. VoiceOver’s rotor and NVDA’s Insert+F7 function fullfill a similar purpose.

The basics:

To launch VoiceOver, click Command+F7. To a launch NVDA, click Control+Alt+N.

In VoiceOver you use VO + Right Arrow to read the next item while in NVDA you use the Down Arrow.
In VoiceOver you use VO + Left Arrow to read the previous item but not in NVDA.

The rotor:

The rotor in MacOS VoiceOver is similar to NVDA’s Insert+F7 function in that it allows the user view and to jump to headings, landmarks, or other HTML elements. To popup the rotor in MacOS VoiceOver presss VO + U. ‘VO’ is the VoiceOver keys (Control & Option) that are pressed in conjunction with a VoiceOver command (like U which launches the rotor). Use the Left and Right arrows to select page elements like: Links, Headings, Tables, Frames, Images, Form Controls, Landmarks, Visited Links, and Non-Visited Links. Once a page element type is selected, the Up and Down arrows can be used to select a particular element from the list and Enter can be used to activate it. The Escape key exits the rotor.

An example of the rotor in MacOS Voiceover poping up a list of headings.

An example of the rotor in MacOS Voiceover poping up a list of headings.

 

Configuring the rotor

You can choose which element types are viewable in the rotor by opening the VoiceOver Utility with VO + F8, then going to ‘Web’ > ‘Web Rotor’. VoiceOver for iOS devices also has a similar rotor that can be configured.

 

 

Features similar to the rotor in other screen readers:

Popping up a list of all links in other screen readers is similar to what the rotor does in MacOS VoiceOver. Insert+F7 in NVDA can pop up a list of all links.

To list all links in MS Narrator, hit Caps Lock + F7 or Insert + F7. See Deque System’s information about MS Narrator for info about keyboard shortcuts.

To list all links in JAWS for Windows, hit Insert + F7. See Deque System’s information about JAWS for info about keyboard shortcuts.

ARIA Menu or Menu bar interaction pattern recomendations

Many websites use Menu or Menu bars for their global navigation to pages in the site. For maximium accessbility it’s best for these menu bars to follow ARIA APG guidelines. In ARIA APG’s recommended menu interaction pattern, because menubar and menu elements are composite widgets as described in Keyboard Navigation Inside Components, Tab and Shift + Tab don’t move focus among the items in the menu. Instead arrow keys are used to move through the menu items and the Enter key is used to follow a link. The right arrow goes to the next item and the left arrow moves focus to previous item. See ARIA APG’s recommended menu interaction pattern for more details about how the arrow keys should behave. Using ARIA APG guidelines as a standard way of building menus will help establish a web convenion that users can learn and apply to a lot of website. Using a standard interaction pattern convension for menus will save users time in not having to learn a different interaction pattern.

ARIA menu and interation pattern resources

What’s new in WCAG 2.1?

The Web Content Accessibility Guidelines (WCAG) are a set of globally adopted technical standards on web accessibility developed by the World Wide Web Consortium (W3C). The guidelines represent a shared, international standard developed by many different stakeholders including: education, industry, disability organizations, government, and accessibility research organizations. The guidelines strive to make websites, apps, electronic documents, and other digital assets accessible to people with a broad range of disabilities, including sensory, intellectual, learning, and physical disabilities.

WCAG covers a breath of success criteria that, when followed by website designers, developers, and content authors, can remove many of the barriers that people with disabilities face when navigating a website or other digital applications. Find out more about WCAG in this article – WCAG 101: Understanding the Web Content Accessibility Guidelines.

What are the new accessibility guidelines in WCAG 2.1?

WCAG 2.1 became a W3C Recommendation in June 2018. There are 17 new SC (success criteria) guidelines in WCAG 2.1:

  1. 1.4 Reflow (AA) – responsive design principals are important to accessibility.
  2. 1.4.11 Non-text Contrast (AA) – requires the icons, UI, and graphics should have good color contrast.
  3. 1.4.12 Text Spacing (AA) – the Text Spacing bookmarklet can help test.
  4. 1.4.13 Content on Hover or Focus (AA) – don’t show unexpected content on hover.
  5. 2.1.4 Character Key Shortcuts (A) – don’t interfere with screen reader shortcuts.
  6. 2.5.1 Pointer Gestures (A) – complex gestures also need a single pointer equivalent.
  7. 2.5.2 Pointer Cancellation (A) – down events must not be used to complete a function.
  8. 2.5.3 Label in Name (A) – visible labels should match the accessible name.
  9. 2.5.4 Motion Actuation (A) – don’t make shaking the phone the only way to complete an action.
  10. 4.1.3 Status Message (AA) – alert the user, but don’t interrupt them.
  11. 1.3.6 Identify Purpose (AAA) – HTML content should provide context, purpose and meaning.
  12. 2.2.6 Timeouts (AAA) – you must store the user’s data for 20 hours.
  13. 2.3.3 Animation from interactions – motion animation trigged by interaction can be disabled. Use media query: prefers reduced motion.
  14. 2.5.5 Target Size (AAA) – touch target size must be 44 x 44px.
  15. 2.5.6 Concurrent Input Mechanisms (AAA) – websites should allow users to switch between input modalities.

Here’s a Good video covering all things new in WCAG 2.1 (53:58).

What are the main WCAG principals of accessibility?

The top four principals of WCAG are: perceivable, operable, understandable, and robust. All new guidelines introduced fall under one of these broad categories. WCAG 2.2 is scheduled to be completed in early 2023 and will include 12+ new guidelines.

  1. Perceivable – people must be able to find your content.
  2. Operable – people must be able to use your website.
  3. Understandable – people must be able to understand your website.
  4. Robust – your website must work with different assistive technology.

See Understanding the Four Principles of Accessibility for more info.

HTML 5 Landmarks and equivalent ARIA Landmark Roles

WAI-ARIA roles provide more semantic meaning to content making webpages more accessbile. ARIA landmark roles provide a way to turn bare <divs> into HTML 5 landmarks. This can be useful in systems where the <divs> can’t be turned into real HTML 5 landmarks for whatever reason.

Comparison of HTML 5 Landmarks and equivalent ARIA Landmark Roles
HTML 5 Landmark Equivalent ARIA Landmark Roles more information
<main> <div role="main"> info about the ARIA main role
<nav> <div role="navigation"> info about the ARIA navigation role
<header> <div role="banner"> info about the ARIA banner role
<footer> <div role="contentinfo"> info about the ARIA content info role
<section> <div role="region" aria-label="Example"> info about the ARIA region role
<aside> <div role="complementary"> info about the ARIA complementary role
<form> <div role="form" aria-label="Contact information"> info about the ARIA form role

Find about more about ARIA (Accessible Rich Internet Applications markup) in the Custom JavaScript/ARIA Widgets Buckeye Learn course.