Ensuring that your website is accessible to everyone is a challenge often overlooked by developers and designers alike. Luckily a Sitecore build gives you all the tools you need to succeed.
Many non-profit, government and crown corporations are required to meet online accessibility requirements for people with physical disabilities, including vision loss, blindness, hearing loss and who may have difficulty accessing web content the way the general public can.
The standards and legislation vary from region to region and typically align to the Web Content Accessibility Guidelines 2.0 (WCAG). Examples include:
- Rehabilitation Act – Section 508 (United States)
- Standard on Web Accessibility (Canada)
- Accessibility for Ontarians with Disabilities Act (Ontario)
Many of these legislations offer a rolling timeframe for compliance; for example, public sector and organizations with 50+ employees in Ontario must confirm to WCAG 2.0 Level “A” by January 2014 and to Level “AA” by January 2021.
For organizations with this requirement, Sitecore can make it easy to enforce many accessibility standards. Please note that many requirements are content-specific and design-specific and cannot be enforced by a CMS tool or automatically verified; as such, a combination of tool validation and training for content authors and designers is required for continued compliance.
WCAG 2.0 Level A – Supporting the requirements
The following table breaks down several key WCAG requirements and how your Sitecore build can address them (and how we do it at Nonlinear). The WCAG requirements and remedies are quite in-depth and are not fully covered by this table.
If you’re already a Nonlinear Digital or Keystone customer, you’ve got an excellent head start towards accessibility compliance. We offer a very cost-effective Accessibility Audit that will cross-check your build, design and content against the WCAG requirements and deliver a roadmap and estimate to full compliance; if you’re interested, drop us a line.
Accessibility check as part of workflow
With Sitecore being the wonderfully extensible platform it is, there is also an opportunity to build an automated validation into the workflow at both the field level with a Custom Field Validation or at the workflow level with an API call to a third-party audit service. This way, your content authors will be able to continually validate new content as it is added.
Sitecore & Nonlinear build accessibility
|| Nonlinear Digital Sitecore build
||Provide text for all non-text content
||For all images in the Media Library the "alt" tag value is mandatory and published with the image
||Provide text alternatives that identify the non-text content with a descriptive text label
||For all videos in the Video Library a video description field is mandatory and should be published with the video
||Ensure that information and structure can be separated from presentation. Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text
||All Nonlinear builds use front-end markup best practices including the use of CSS for layout structure and styling and avoiding the use of embedding important text within images.
The builds also make use of HTML headings to organize content, using properly nested H tags (H1, H2, etc) to allow user agents and assistive technologies to identify section headings and navigational structure.
Mandatory form fields are clearly marked with an asterisk at the end of the label, with instructions indicating so.
||All functionality of the content is operable in a non-time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input
||Website content is operable through a keyboard interface without requiring specific timings for individual keystroke
||Allows users to control time limits on their reading or interaction
||Moving elements, such as homepage slides, can be configured to permit pausing of slides
||Web pages have titles that describe topic or purpose
||The Sitecore build provides several title fields for navigation, page title and breadcrumb. Content authors must ensure they are sufficiently descriptive of page content
||If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability
|| The front-end code is structured such that tabbing follows a logical order of top navigation, left navigation and main content
||If an input error is detected, the error is identified and described to the user in text
||Input errors are highlighted on submit and described in red text adjacent to the form field where they occurred
||The primary natural language or languages of the web unit can be programatically determined
||The website is published with the default human language identified in the HTML element within the lang attribute ("en")
||When any component receives focus, it does not cause a change of context
||The build does not include components that trigger context-changing events (such as form submissions or new windows launched) when receiving focus
||Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order), unless the authored unit contains instructions before the control that describe the behaviour
||Forms are built such that entering data or selecting a form control has predictable effects
||Labels or instructions are provided when content requires user input
||All pages with forms provide a field for instructions and descriptive text. Labels are mandatory for form fields
Content and design specific guidelines
The following table outlines a selections of additional WCAG 2.0 Level A requirements that cannot be verified as easily by a tool, and require human judgement of both design and content elements. The recommendations column includes how these requirements can be addressed.
||Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and clearly labelled as such
||Ensure all videos have a Closed Caption option. We've found a helpful blog post on accessibility for embedded YouTube videos to help you out
||Any information that is conveyed by colour is also visually evident without colour
||Review of main website imagery and whether any images convey colour-dependent information
||Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound
||Review of content to ensure users can access instructions for using content without knowledge of share or position of objects (ie: "button to the right"). References to "Above" and "Below" are generally accepted
||Content does not violate general flash threshold or the red flash threshold
||Review all video content to ensure web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds
||The purpose of each link can be determined from the link text alone or from the link text together with its programatically determined link context, except where the purposes of the link would be ambiguous to users in general
|| Review all links to ensure link text is meaningful and coveys purpose
If you are still wrapping your head around how best to follow the guidelines, reach out and we can discuss how best to get your website in line with the current regulations.