CMS Integration Phase

This section highlights accessibility considerations specific to back-end development, and CMS integration.

Perceivable

1.1 Non-text content

Important Images have a text alternative.

Information conveyed by an image should have a text alternative in case the image cannot be viewed. This is a basic concept, but there is an art to writing appropriately descriptive text to replace an image.

How to do it

On the back-end, we need to provide a way to add alt text where needed, handle decorative images with an empty alt="", and role="presentation", and ensure that any functional images generated in the templates have alt text in place.

Decorative Images: Images used as spacers, icons, purely decorative, and CAPTCHA images, or other situations where the alt attribute would be redundant with the other page content.

<p>
  <img src="sleepingdog.jpg" alt="" role="presentation">
  Let sleeping dogs lie: Let sleeping dogs lie is a proverb that means “don’t initiate trouble. If something that could be troublesome is quiet, then leave it alone”.
</p>

Functional Images: Images used as buttons or other interactive elements.

<a href="javascript:print()">
  <img src="print.png" alt="Print this page">
</a>
UI Note:

While front-end design elements can rely on hard-coded alternate text, what does this look like for editors? This can be as simple as requiring a decision upon upload of an image - either entering an alternate title or checking a "decorative" box before saving the image within the CMS.

More detailed information is available in this tutorial for writing text alternatives

Critical Form inputs have properly associated text labels.

Labeled form fields mean a screen reader can explain what information should be entered.

How to do it

Whenever possible, this should be accomplished with a for attribute on the label that references the id of the associated field.

<label for="firstname">First name:</label>
<input type="text" name="firstname" id="firstname">

Frames are titled.

Descriptive, unique titles allow screen readers explain what is in any frame on a page, making navigation easier.

How to do it
<iframe src="banner-ad.html" id="testiframe"
  name="testiframe" title="Advertisement">
  <a href="banner-ad.html">Advertisement</a>
</iframe>

1.2 Audio and video

Critical Text transcript is included for all prerecorded audio or video.

Audio-only and video-only content needs to be supported by text transcripts that convey the same information as the media.

How to do it

Open question - Is there anything that needs to be done to manage or associate transcripts with audio or video?

Supplimental description for video with sound.

Provide more information than the regular soundtrack offers. This includes movements that are not audibly explained in the video, or adding context to visual information.

How to do it

Open question - Is there anything that needs to be done to manage or associate a supplimental description with audio or video?

Level AA Supplimental descriptive audio for video with sound.

An audio description is an edited version of a video’s soundtrack that adds more information than the regular soundtrack offers. This might mean narrating movements that are not audibly explained in the video, or adding context to visual information.

How to do it

Open question - Is there anything that needs to be done to manage or associate a supplimental description with audio or video?

1.3 Page structure

Important Headings, lists, and special text are used appropriately.

Headings and other tags provide information about what content is available, and which piece is most important on the page. This information allows people using assistive technologies to “see” an overview of the page and jump quickly to the section that is relevant to them.

How to do it

Provide access to a set of heading style classes so editors can visually adjust headings without breaking the heading order of the page. Typically, there is a heading class .h* that mirrors the style of each heading tag <h*>.

Creating tables in a rich text editor

TinyMCE and CKEditor are the most common editors in the CMS we use. Both can generate clean markup, but make it hard to maintain a consistent table style across the site. Enabling an editor to use class-based styles in some way provides a better experience and end product.

Here are some features and limitations.
Feature TinyMCE 4 CKEditor 4
Wrap table in div with a class No No
Add a class on the table tag Yes* No
Can add headings Yes Yes
Can add a caption Yes Yes
Can add thead or tfooter No No
Can set percent-based widths Yes Yes
Can force percent-based widths Yes* No
Can suppress styling options Yes* No
Prestyled tables Yes** No

* This requires adding the tables plugin to TinyMCE.

** TinyMCE has the concept of a template that drops in predefined HTML. This could offer a way to start editors off with a good base table.

Important The page order is clear and makes sense.

Maintaining a logical order of elements on the page, both visually and in the source code avoids confusion for all users.

How to do it

This is mostly a front-end thing, but another set of eyes on the final page templates is always good.

Pro Tip - Try turning off all CSS and see if the flow of the page still makes sense.

Operable

2.2 Moving content and time limits

Important Any page or application with a time limit, offers the user options to turn off, adjust, or extend that time limit.

How to do it

Do ONE of the following:

  • If possible, give your users an option to turn off the time limit before it begins.
  • Or offer the option to adjust the time limit before it begins, over a range of at least ten times the default setting.
  • Or provide the option to extend the period at least twenty seconds before it expires. This must be a simple action like clicking a button and must be available to use at least ten times.

Understandable

3.1 Languages

The language of the page is identified using the HTML lang attribute.

How to do it
<html lang="en">

Provide a way for an editor to set this attribute. Note that this should only be used for natural languages, not programming langauges.

Level AA The language of page content that is in a different language is identified using the lang attribute.

How to do it
<blockquote lang="es">
   Hola Mundo!
</blockquote>

3.2 Predictable site behavior

When an element received focus it doesn’t change the page in confusing ways.

How to do it
  • Don’t open a pop-up window, submit a form, jump keyboard focus to another element, etc. when an element receives focus.
  • Exceptions - Opening a drop down menu or adjusting a link style on focus aren’t really a change of context, so they don’t cause a problem here.

Interacting with a control doesn’t change the page in unexpected ways without informing the user ahead of time.

Mostly this means only submit form data when a user chooses to click a submit button. But there is some nuance.

How to do it
  • Forms must not auto-submit when all fields are filled.
  • Focus must not automatically jump to the next field in a form once a field is complete.
  • Using a control (like selecting yes or no, or choosing an item in a select box) must not automatically perform the action.

3.3 Forms and error handling

Required form elements or specific format requirements are noted in the element’s label.

Identify any mistakes that you can detect and explain what is wrong close to the form element.

How to do it
  • If a form requires input in a certain format, show and describe the required format.
  • If a mandatory field is empty, highlight the field and explain what’s required.
  • Build forms to be forgiving, accepting variations on the formats you prefer.
  • Highlight mistakes in forms with colors AND symbols.
  • Don’t clear a form if a user makes a mistake. Save the information and allow the user to edit their error and continue.

Demo - Here is a set of form examples based on our current best practices.

Level AA If an input error is detected (via client-side or server-side validation), provide suggestions for fixing the input.

This guideline adds the requirement to make suggestions on how to fix form errors.

How to do it
  • If the error is in the format of the input, the suggestion shows the correct format (for example, ‘The date must be in the form DD/MM/YYYY’).
  • If the error is because the input needed to be from a limited list of values, provide these values and explain them.
  • If a user makes an error, provide a list of links that the user can follow to jump back to correct their input.

Level AA If the user can change or delete legal, financial, or test data, the changes/deletions can be reversed, verified, or confirmed.

This is about error prevention AND reducing risk from errors by adding in confirmation stages to processes that involve legal or financial transactions.

Note - This guideline applies to deletion of data as well as submission.

How to do it
  • Provide a confirmation webpage that gives the user a chance to read a summary of everything they have input and positively confirm their actions (especially if inputs were spread over several pages in the process).
  • Inline form validation and clear error messages help support this guideline.

Robust

4.1 Maximize compatibility

HTML/XHTML validates without significant parsing errors.

Make sure your markup is good. Following specs makes a site more likely to work as expected with any assistive technology.

How to do it

Major errors and broken code are the problem here. Minor warnings generated by an automated validator don't necessarily mean failure.

There are lots of these, but here is the W3C validator.

Validity - Chrome extension to validate HTML on the current page.