-
Notifications
You must be signed in to change notification settings - Fork 0
Accessibility Menu
- What is meant by accessibility?
- For the learner: How does the accessibility feature function in Adapt?
- For the course author: Make your course accessible.
- For the plug-in developer: Make your plug-in accessible.
Accessibility is a short way of referring to:
- the features in Adapt that make content usable to persons with low- or no-vision and to those who do not use a mouse;
- industry standards such as the W3C's Web Content Accessibility Guidelines (WCAG) and regional standards such as the Equality Act in Europe, BS 8878:2010 in the UK, and section 508 in the US.
The goal of Adapt's accessibility feature is to aid users and screen readers by making every piece of content tabbable and readable. The rationale behind it is to ensure the Adapt framework adheres to the W3C2 AA standards where possible.
All Adapt courses have the accessibility feature built-in. However, it must be enabled by the course author and activated by the learner.
To activate the accessibility feature while viewing a course, press the Tab key. A button is displayed: "Turn accessibility on?". Press the Enter/Return key. (If the Enter/Return key is not pressed, the button will continue to display until tabbing encounters the first naturally tabbable element in the page.)
Once the feature is activated, pressing the Tab key navigates the learner through content, focused content regions are highlighted with an outline, and ARIA labels are enabled for assistive technology such as screen readers.
The course author can ensure a course is accessible by taking several steps:
- Enable accessibility
- Use plug-ins that support accessibility
- Add _global ARIA labels for non-core plug-ins
- Attend to images: alt text
- Attend to images:
no-state - Attend to inaccessible components:
not-accessible
- To enable accessibility in a course while working in the Adapt authoring tool, set accessibility to true in the Project Settings.
- To enable accessibility while working in the Adapt framework, set
"_isEnabled"to true within the"_accessibility"section of config.json. If accessibility is not enabled, the learner cannot activate the feature.
All plug-ins (components, extensions, menus, and themes) bundled with the Adapt framework and authoring tool support accessibility. This means their code includes ARIA roles, regions, and labels and supplements tab indexes where necessary.
You cannot assume that a third-party plug-in adequately supports accessibility. Look for evidence in the following.
- README.md. Chances are you located the plug-in either through the Adapt community Plug-in Browser or by searching GitHub repositories. Either way makes it easy for you find and review the repository's README. Look for notice of accessibility support or mention of WAI AA or WCAG.
-
Code. Look in the plug-in's template for ARIA. You don't need to know JavaScript. Here's what you do:
- In the plug-in's GitHub repository, open the folder named templates. There you will find one or more files whose name ends with the .hbs extension. Open each file in GitHub and examine its content (no need to download it).
- Look for phrases that begin with
aria-, such asaria-region,aria-role, andaria-label. Also look for the presence ofa11y_text. This is evidence that the developer has made an effort to support Adapt accessibility features. It is no guarantee that the effort was successful, but the plug-in meets the basic requirement for testing.
The bulk of Adapt course content is found in presentation components and question components. The sighted learner has the ability to scan the page to determine what next step she'll take to access the content. Because low-vision can impede this ability, each component presents an aria-label that describes how it functions. ARIA labels are not visible; they are announced by screen readers. Regardless of how many times a particular component is used within a course, the same description of it is announced to the learner.
The Adapt framework gathers these descriptions in the course.json file in a section called "_globals". You'll find the same descriptions in the Adapt authoring tool in the Accessibility section of the Project configuration menu. Adapt provides descriptions for the core plug-ins. It cannot provide descriptions for plug-ins it does not about. If you use a third-party plug-in AND if the accessibility feature is important to your learners, ensure your plug-in has a description in "_globals".
All images should have an alt attribute. The value assigned to this attribute is often called "alt text". Whether or not the alt attribute is assigned alt text depends on the purpose of the image. Nonetheless, the alt attribute should be present in all cases, even if it is not assigned a value, e.g., alt="".
Graphics in courses fall into two broad categories: images that convey course content and those that don't. Focus on those that do. Decide which images represent information significant to the content. Assign alt text to these images. Balance your decisions with a recognition of the additional time it will take your visually impaired learner to scan through the page. For example, alt text that describes the physical characteristics of your course avatar may have significance for some topics but not for others.
Give care to charts and diagrams. If an adequate description and interpretation is provided in the text, it is possible that no alt text is needed.
Note: Often confused with the alt attribute, the title attribute plays a minor role in accessibility. It can hinder efforts to be accessible if employed improperly.
All components that conform to Adapt standards by extending the componentView.js report their state—complete or incomplete—in ARIA labels. This is achieved through state.hbs which componentView.js automatically appends to the component.
Reporting state is necessary for components that are interactive. But reporting state for those that are not, such as adapt-contrib-blank and adapt-contrib-graphic, is unnecessary and may even distract the learner.
To override this default behaviour, add the class no-state to the non-interactive component. This class has no inherent impact on CSS styles. Instead, its presence prevents state.hbs from being added to the component. adapt-contrib-blank automatically adds the class to itself. adapt-contrib-graphic does not. Although rare, there may be scenarios in which it is important to track whether an image and/or its alt text have been presented to a learner. A clue may be whether you are tracking the image with adapt-contrib-pageLevelProgress for sighted learners. For this reason, no-state is not automatically added to Graphic. If Graphic and its alt text do not contribute significant content to the course, it is recommended to assign it the class no-state.
Some components can never be accessible. Components which rely on making sighted judgments or which require a level of visual special awareness can be skipped over when the course has accessibility enabled. To achieve this, assign the component the class not-accessible. Doing that will remove the component from the tabbing order. Be sure to configure these components as optional, since they will never be completed by the learner who relies on tabbing.
The component developer can take advantage of the accessibility features present in the Adapt core by
- extending componentView.js
- adding ARIA roles and labels to your template
//Example of ARIA role and aria-label:
<div class="mynewcomp-inner component-inner" role="region" aria-label="{{_globals._components._mynewcomp.ariaRegion}}">Essential technical guidance can be found in three documents:
- The Adapt Accessibility Standards and Guidelines provides instruction and examples useful for implementing ARIA in templates.
- jquery.a11y README provides usage examples, functions references, and style descriptions.
- Accessibility in Adapt: A Technical Perspective provides information about the properties, methods, and events found in accessibility.js and jquery.a11y.js.
- processing significant user-supplied text in your template with
a11y_text
//Example of processing body text with a11y_text:
<div class="mynewcomp-content-body-inner">{{{a11y_text body}}}</div>- providing sample text in example.json for inclusion in course.json's
_globals._components
//Add the _mynewcomp section to the _globals in your course.json:
"_globals": {
"_components": {
"_mynewcomp": {
"ariaRegion": "This component is made up of things that do this and that. Select the thingamajig to access the content.",
"instruction": ""
}, Note: Some components can never be accessible. Those which rely on making sighted judgments or those components which require a level of visual special awareness should be specifically labeled as inaccessible. To mark a plug-in as inaccessible, add the following line of code to the plug-in's
preRenderfunction:
preRender: function() {
this.$el.addClass("not-accessible");
// other code
},- [Accessibility: worked example](https://github.com/adaptlearning/adapt_framework/wiki/Accessibility:-worked-example)
- resources
(Saving these for later use:
https://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/
http://www.karlgroves.com/2013/03/02/name-state-role-and-value-whats-it-all-about/)
- Framework in Five Minutes
- Setting up Your Development Environment
- Manual Installation of the Adapt Framework
- Adapt Command Line Interface
- Common Issues
- Adapt API
- Adapt Command Line Interface
- Core Events
- Core Model Attributes
- Core Modules
- Peer Code Review