Related Links
You can download PDF versions of the Content Contributor's, Administrator's, and Elements Reference documents from the support section of paperthin.com (requires login).
For technical support:
Depending on the level of support required, web visitors with disabilities make use of a variety of assistive technologies to consume page content. CommonSpot provides a set of tools designed to analyze page components for accessibility so you can optimize them for the devices and web access strategies most often used by individuals with limitations.
Support for accessibility considers these major disability types and their requirements:
In addition to actively using CommonSpot's left-pane Accessibility tools, and the many external options available for evaluating accessibility (including the wc3's validation tools - see Other Resources), becoming conscious of the different techniques and technologies used by disabled visitors, and how content appears to them, will help you improve the user experience for all visitors to your site. Following the guidelines below will help you to effectively use CommonSpot to optimize content organization, site and page navigation, content labeling, and other site components for greater accessibility.
Making sure content works well for screen-reader users and people with cognitive and mobility issues, who are often keyboard-centric, is one of the major accessibility challenges. Tailoring content for these audiences primarily involves providing:
Note that these suggestions are not exhaustive or representative of any particular set of applicable laws. For expert advice, consult experienced accessibility practitioners, and/or people with disabilities, through mailing lists, forums, or other means.
Besides different abilities, visitors have varying interests in and knowledge of the content available on your site and how to find what they're looking for. To best serve this variety of needs, provide multiple paths to the content you offer to make it easy to locate both throughout the site and on each page.
Some useful navigation approaches are:
Page title is the main indicator of location within a site. The title displayed in the title bar is also announced by screen readers. Make sure titles are descriptive and use standard <title> tags, so they are recognized by assistive technologies. CommonSpot requires unique page titles and by default assigns a <title> tag to each page name, but if your site uses a customized headStruct.titleTag, this may be a concern.
It should be possible to reach all content through tab and arrow key conventions and key combinations. Nothing should trap keyboard-only users from using standard keyboard techniques to navigate a site or individual pages within a site. Test pages using the keyboard only. If it's necessary to use non-standard modifiers or other special keys or sequences, indicate this requirement in advance (see notes on "front-loading" below).
Visitors who have difficulty perceiving, understanding, or remembering site content often find it easier to navigate pages with similar layouts. Once they master main content, search bar, and navigation location, etc., they can apply that knowledge to other pages. CommonSpot templates are designed to help you develop and maintain standard page and navigation design. (See below for a common drawback and a workaround using Skip Navigation links.)
To make it easy for screen readers and keyboard-centric users to more quickly access main content and avoid repetitive announcements or tabbing for global menus, use Skip Navigation (or Skip To Main Content) links, which point to named anchors linked to main content. In CommonSpot, you can add skip links and target anchors to a common template so that pages inherit them automatically.
Test skip links to make sure they behave as expected. For example, check that tabbing doesn’t return you to the top of the page once you’ve followed a skip link. This can happen when using explicit tabindex settings or as a function of content ordering issues. Ideally, arrange for assistive technology users to test your links with tools they typically use.
Some sites opt to hide Skip Navigation links from sighted visitors (see tips for hiding elements below). If you hide Skip links, make sure they become visible on focus, or sighted keyboard users will be unable to use them. Note that showing, these links is considered good business by many, indicating an awareness and concern for accessibility.
Modern web pages typically contain content designed for non-sequential reading. Features such as common headers and footers, multiple sets of common navigation links, sidebars, etc. form supporting information for main page content, which is often extensive enough to benefit from a structured outline. Hierarchical headings can help clarify information status and meaning for pages with various organizational schemes.
According to a 2012 survey of screen reader users, headings and ARIA landmarks are the two most common ways for the blind to navigate page content. To best support these methodologies:
ARIA (Accessible Rich Internet Applications) Landmark roles (or "landmarks") provide labels that give assistive technology users another way to orient themselves within a page and navigate through sections. Screen readers use landmark navigation to present content through common, semantic navigation landmarks. This allows sites supporting this standard and assistive technologies to provide a consistent navigation experience. At this time, web standards define eight landmark roles for content regions, including Search, Navigation, Main, and Content Info. Roles are generic, not specific to the content itself. For details, see http://www.w3.org/TR/wai-aria/roles#landmark_roles.
The Paciello Group blog provides good background and guidance for constructively applying landmarks. See:
http://blog.paciellogroup.com/2013/02/using-wai-aria-landmarks-2013/.
It's easy to assign landmarks in CommonSpot:
To ensure that blind users, low-vision users, keyboard-only users, and sighted users read pages in the same order, create pages whose source order matches the display order (WCAG 1.3.2): http://www.w3.org/TR/WCAG-TECHS/C27.html.
Screen readers generally interpret page content using the order found in the HTML source, which may not match the visual display of content. For example, layout tables using merged cells (rowspan or colspan > 1) or certain CSS techniques (absolute positioning, float: right, others) can produce an order that differs significantly from the order contained in the HTML.
Some browsers have an option to disable all styles, either natively or using the Web Developer extension, without affecting formatting controlled by tables. You can use this option to view pages without styles. Alternatively, you can View Source to review order, although this can be challenging for pages with complex code.
As helpful as headings are, too many can create clutter, which can become a problem in itself. Nobody wants to wade through unnecessary navigation to find what they’re looking for.
Each link presented to assistive technology users should clearly describe its target.
Use the Links view in CommonSpot’s Accessibility panel for a quick, context-free review of all links on a page.
Visually impaired users should understand the underlying information communicated by images. The option to require ALT tags for all site images and objects is enabled by default in CommonSpot (see Site Admin - Content Creation - Accessibility Properties), but ensuring that text is descriptive and helpful is a manual process. Use the Image Alt Text view in CommonSpot’s Accessibility left pane to review and correct all ALT text and check for missing tags.
For forms, this is controlled by CommonSpot, which provides good labeling support. Labels are very important for custom-coded forms (see the technical note below for more information).
Use the Forms view in CommonSpot’s Accessibility panel to review the labels assistive technologies actually see and to review potential problems.
CommonSpot also includes the ability to define default text in edit control fields, such as search fields, as shown below, to improve accessibility. You can define search field default text for edit controls for a simple form, search, and other form fields accepting user-entered data.
In general - for all users - it's best to position important information early so that site visitors can act on it without consuming the whole page. The w3c site provides some great examples of front-loading content. See http://www.w3.org/WAI/wcag-curric/sam110-0.htm and related articles. See also Check Content Order below.
Tables used to display related information in structured rows and columns are often referred to as data tables. Layout tables control content placement on the page and were the only means of controlling position before browsers had widespread support for modern CSS techniques. If you can, avoid using layout tables.
For best compatibility with assistive devices, data tables should have:
If used, tables that don’t contain actual tabular data should essentially be invisible to assistive devices. Layout tables should not have:
Use the Tables view in CommonSpot’s Accessibility panel to quickly review the tables on a page. It shows the following for each table, including warnings:
Without contrast, users with impaired vision may not be able to properly distinguish meaningful content. However, be aware that ultra-high contrast designs may overstimulate or distract visitors with certain kinds of autism, and may not be visually appealing to Marketing. Look for a middle ground.
There are specific numerical standards for color contrast and accessibility, as well as a variety of browser add-ins, applications, and web sites that analyze contrast using various methodologies. Some well-known ones are:
Because appropriate color contrast can be difficult to determine mechanically, all tools are best used in combination with a visual check. For example, an analyzer may miss white text positioned over white clouds in a background image or issues that occur when pages reflow on resize. For this reason, make final color contrast judgements by eye. Take the time to consider whether your site’s overall color palette provides a usable degree of contrast, and check individual pages for problems.
People with color impairments may miss it completely.
Fully justified text has inherent letter and word spacing irregularities that can make reading it difficult for users with visual or cognitive impairments.
Long lines make it harder to maintain continuity as your eye scans back from the end of one line to the start of the next. This is true for visitors without visual or cognitive impairments, and can be especially important for visitors with them.
In general, it's best to serve content that is accessible to all users, regardless of ability. Among other reasons, it’s helpful when everyone is literally "on the same page" (see Check Content Order).
However, for cases where it’s genuinely appropriate to hide content from sighted users, position that content far off-screen, above or to the left. In CommonSpot, you can create a CSS class for this purpose in a global style sheet and apply it as needed.
Be aware that screen readers generally ignore anything hidden by CSS, both in-line and via CSS classes, making it a poor strategy for hiding content from sighted users that you still want visible to screen readers. For this reason, positioning it off-screen is preferred.
For aesthetic reasons, designers and other stakeholders often request removal of the dotted ring that appears by default around focused links and other elements. Using CSS to hide this indicator eliminates a valuable cue for sighted or low-vision users. Worse yet, some sites use javascript to remove focus from links (onfocus=”blur()”), which prevents keyboard users from interacting with them at all.
Don’t hide the focus indicator or remove focus. See the Paciello Group blog for an alternative approach.
Changes to the natural tabbing order cause unexpected behavior for keyboard users. This can be particularly disorienting for people with limited vision, making it hard for them to understand what happened, why, how they arrived at a location on the page, or how the page is structured.
Content like this can trigger seizures in people who are prone to them. While there’s no absolute measure for what constitutes a problem, flickering or strobe-like graphics and media that flash between 2 and 55 times per second are called out by Section 508 standards as potentially dangerous.
Dynamic or Ajax-based content presents another set of accessibility challenges. If you’re writing this kind of custom code, you’ll need to consider accessibility in this context.
WAI-ARIA defines standard interaction models and ARIA attributes for some common user interface scenarios. Following those guidelines helps make this kind of content more predictable for users, and more perceivable by assistive technologies.
Creating highly interactive and fully accessible content from scratch is not a trivial task. Best practices in this area are beyond the scope of this document; however, researching the various JavaScript UI frameworks available and their level of accessibility is a good place to start.
The sectioning elements <article>, <section>, <nav>, and <aside> are new in HTML5. Although they promise the benefit of containers with actual semantic meaning (as opposed to <div> and <span>, which have none), they function independently of the outline structure provided by HTML headings. For more information, programmers may want to review the description of the wc3 outline algorithm
To the extent that browsers and assistive devices reflect sectioning concepts at all, they follow the model defined by the HTML5 algorithm. This algorithm is rational and robust, but because the way it works is not immediately obvious, and because HTML sectioning elements and HTML headings do not inherently combine to support a single coherent outline structure, HTML5 sectioning elements are not enabled by default in CommonSpot. Site administrators must explicitly activate use for each site through Site - General Settings. Once enabled, HTML5 Elements are available as Container Type options in Layout Properties for Container Elements.
For the purpose of creating accessible outlines, the simplest approach is to avoid using sectioning elements entirely, despite the potential benefit of the semantic meaning they provide.
Web developers need to research this topic in detail, discuss the pros and cons with managers and/or site administrators, and together make an informed decision to use them or not. Smashing Magazine has an excellent article explaining how the outlining algorithm works in practice and why:
http://coding.smashingmagazine.com/2013/01/18/the-importance-of-sections/
If you do decide to use sectioning elements, plan on learning about outline construction in that environment, and educating contributors accordingly.
If you’re creating custom code that includes form fields, label every form element so that it is readable by assistive technologies. Use real HTML <label> elements, not styled spans, etc., so they are recognized as labels, not text. There are two ways assistive technologies connect labels to form items - always use at least one. The first is the preferred method:
CommonSpot also includes the ability to define default text in edit control fields, such as simple form fields, search fields, or other fields accepting user-entered data. See Defining Default Text in Edit Controls.
The web provides a wealth of information for developing accessible sites. Some good starting points are:
WebAIM also has a very good mailing list: http://webaim.org/discussion
Your organization might also consider hiring outside professionals in this area. The many companies dedicated to improving web accessibility offer services in:
Related Links
You can download PDF versions of the Content Contributor's, Administrator's, and Elements Reference documents from the support section of paperthin.com (requires login).
For technical support: