Making Learning Products Accessible
1 like48 views
The document outlines Magic Software's approach to developing accessible learning products in compliance with WCAG 2.0 level AA guidelines, focusing on usability for students with low-incidence disabilities, including vision, hearing, and motor impairments. Key practices involve ensuring keyboard navigation, providing alternative descriptions, and incorporating captions and transcripts for audio and visual content. Additionally, it addresses frequently asked questions regarding accessibility standards, user roles in education, and the application of Universal Design for Learning.
![DEVELOPMENT APPROACH
VISION IMPAIRED
Three things work together to create the user experience for people using screen readers.
- Keyboard navigation and Gestures
- Color Contrast
- Alternative descriptions of visual assets
Screen reader resources
In order to develop for screen reader users, it is necessary for developers and unit testers to
review their work using a screen reader. The following are standards and design guides that
are provided to establish this capability.
- http://www.w3.org/TR/WCAG20/
- http://webaim.org/
Keyboard navigation
The following is required for a successful screen reader experience.
- Users can tab through all active elements on the screen.
- There is an obvious tab order, typically this is left, right, top bottom.
- There are no keyboard traps where keyboard users get stuck and can no longer navigate.
- CSS is used to make the browser’s focus ring distinctly visible.
GENERAL APPROACH
Use the correct HTML element
Use HTML5 semantic elements for any markup used in Learning Product design. This means that buttons
should use the <button> and not a generic container like a <div>. This way user agents can correctly
interpret and present a Learning Products content even as browsers and user agents are updated. Using
the appropriate <h1>-<h2> elements facilitate navigation and provide the ability to skim the content. ]
New elements like <section> and <article> further facilitate user understanding.
Use WAI-ARIA
WAI-ARIA stands for Web Accessibility Initiative–Accessible Rich Internet Applications. WAI-ARIA can be
used to increase the accessibility of content by assigning roles and properties to HTML5 elements.
http://www.w3.org/WAI/intro/aria.php
Usage of canvas element
The <canvas> provides specific functionality that makes it appropriate for use in drawing tools and for
presenting user-created charts. However, <canvas> does not support ARIA and this limits the accessibility
of other types of widgets developed using <canvas>. For this reason, <canvas> should be used to develop
drawing tools and to create on-the-fly graphics like charts and graphs, but should not be used to create
widgets and other interactive.
3
These features are implemented using the native accessibility features of the development tools.](https://image.slidesharecdn.com/makinglearningproductsaccessible-161102115934/85/Making-Learning-Products-Accessible-3-320.jpg)
Making Learning Products Accessible
- 1. Making Learning Products Development approach,Tools & FAQ’s for Accessible The information in this document has been provided to you by Magic Software on a confidential basis and is to be used by you and your authorized agents only for the agreed purpose. This document and its contents are not to be disseminated to any third person without Magic Software’s express permission. bringing learning to life magic software Rishi Raj Singh Gera Consulting Head, Magic Software E: [email protected] P: +1-917-257-5983
- 2. OVERVIEW Magic Software develops products and platforms according to the WCAG 2.0 level AA guidelines. The goal is to make Learning Products useful to students, teachers, and administrators with low-incidence disabilities. The information below is offered to enhance understanding of this requirement and also to communicate the best practices employed by Magic Software development groups. The Development efforts for accessible Learning Products should focus on these low-incidence disabilities. Vision impaired A blind or low vision person must be able to navigate and interact with our materials using only a screen reader and keyboard. This is accomplished by developers and testers becoming proficient with a screen reader. Low motor ability Supporting keyboard controls for desktop offerings provides access to students with low motor abilities. This is often already accomplished when students with vision impairments are supported. Hearing impaired Students with hearing impairments require captioned video and audio transcripts for primary source audio. ACCESSIBILITY FEATURES The four accessibility features described below comprise the foundation of the Web Content Accessibility Guidelines 2.0 AA. Ideally a Learning Product design should include these features to provide a complete experience for students with vision impairments. 1. Users can navigate the content using only the keyboard. Users of mobile devices can navigate using the touchscreen in screen-reader-mode. 2. The content and structure can be understood by a person using a screen reader like NVDA, JAWS, iOS Voiceover, Android Talkback and Chromevox on Chromebooks. 3. Text equivalents for all non-text media. This includes captions for video, audio transcripts, and alternative descriptions for images, animations, and videos. 4. All visual presentations follow the WCAG 2.0 AA visual guidelines. 2
- 3. DEVELOPMENT APPROACH VISION IMPAIRED Three things work together to create the user experience for people using screen readers. - Keyboard navigation and Gestures - Color Contrast - Alternative descriptions of visual assets Screen reader resources In order to develop for screen reader users, it is necessary for developers and unit testers to review their work using a screen reader. The following are standards and design guides that are provided to establish this capability. - http://www.w3.org/TR/WCAG20/ - http://webaim.org/ Keyboard navigation The following is required for a successful screen reader experience. - Users can tab through all active elements on the screen. - There is an obvious tab order, typically this is left, right, top bottom. - There are no keyboard traps where keyboard users get stuck and can no longer navigate. - CSS is used to make the browser’s focus ring distinctly visible. GENERAL APPROACH Use the correct HTML element Use HTML5 semantic elements for any markup used in Learning Product design. This means that buttons should use the <button> and not a generic container like a <div>. This way user agents can correctly interpret and present a Learning Products content even as browsers and user agents are updated. Using the appropriate <h1>-<h2> elements facilitate navigation and provide the ability to skim the content. ] New elements like <section> and <article> further facilitate user understanding. Use WAI-ARIA WAI-ARIA stands for Web Accessibility Initiative–Accessible Rich Internet Applications. WAI-ARIA can be used to increase the accessibility of content by assigning roles and properties to HTML5 elements. http://www.w3.org/WAI/intro/aria.php Usage of canvas element The <canvas> provides specific functionality that makes it appropriate for use in drawing tools and for presenting user-created charts. However, <canvas> does not support ARIA and this limits the accessibility of other types of widgets developed using <canvas>. For this reason, <canvas> should be used to develop drawing tools and to create on-the-fly graphics like charts and graphs, but should not be used to create widgets and other interactive. 3 These features are implemented using the native accessibility features of the development tools.
- 4. 4 Here is expected key behavior. This functionality is supported by WAI-ARIA. - Tab, moves focus point to the next active element. - Shift tab, moves focus point to the previous active element. - Enter and spacebar, mouse click. - Arrows, sliders, and dropdown menu options. - Control with left/right arrow rotates a draggable object. - Esc, close dropdown menu. Gesture navigation The following gestures must be supported on touch-screen devices. - Touch, reads name of item. - Double tap, mouse click. - Flick right and left, tab and reverse tab. - Two finger swipe down, reads from focus point. - Three finger swipe sideways, scrolls left and right. Color See the accessibility-visual page for the list and description of the WCAG 2.0 AA color guidelines. Alternative descriptions Alternative descriptions include images, videos, animations, and in some cases interactive activities. Alternative descriptions are delivered two ways. HTML alt attribute - 255 characters of plain text. - Required for all navigation and content images. Long description - Delivered via ARIA-describedby or ARIA-describedat. - Supports structured content like lists, tables, and MathML. Many assets can be described with just an alt attribute, but some assets need both an alt attribute and a long description. An image can have an alt description without a long description, but if an image has a long description, it must also have an alt description. Math Math expressions are encoded in MathML format and presented using MathJax. A text version of each Math expression is translated using a MathML-to-text utility. The resulting alternative text refers to the MathML island using ARIA-describedby. LOW MOTOR ABILITY Alternative mice, SNP devices, and switches all rely on a keyboard interface. For this reason users with low motor ability are supported by implementing keyboard navigation. This is true even when the offering cannot be made accessible to blind students.
- 5. 5 HEARING IMPAIRED Video content Captions are built for all narrated videos unless a text equivalent of the narration is presented on screen. Audio content Audio transcripts are built for primary source audio unless a text equivalent is presented on screen. TESTING APPROACH Core Accessibility Principles tested are as follows: Perceivable Information and user interface components must be presentable to the users in a way they can perceive. User Interface components and navigation must be operable. Information and Operation of user interface must be understandable. Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. Operable Understandable Robust ACCESSIBILITY PRINCIPLES REQUIREMENTS TESTED DESCRIPTIONS Text Alternatives for -Images -Time based media -CAPTCHA’s Adaptable presentation Use Color and Contrast Effectively Organize content in a meaningful sequence Content need to work with key- board – primitive cursors and access keys Provide enough time to read and use Not design content in a way that known as could cause could lead to seizures Help user to navigate, find content themselves Use plain language Consistent and Predictable Interface Input assistance Use Valid markups and standards Describe Name, Role, Value of all interface controls
- 6. TESTING TOOLS - Windows: NVDA/Firefox (Recommended for developers.) - OSX: VoiceOver/Safari - iOS: VoiceOver/Safari - Chromebook: Chrome/ChromeVox - Windows: JAWS/IE Other Tools Accessibility Inspector for Firebug: https://code.google.com/p/ainspector/ WAVE(Firefox): http://wave.webaim.org/toolbar/ Web Accessibility Toolbar (WAT): http://www.paciellogroup.com/resources/wat/ Accessibility Evaluation Toolbar (Mozilla): https://addons.mozilla.org/en-us/firefox/addon/accessibility -evaluation-toolb/ FireEyes (Deque): http://www.deque.com/products/fireeyes/ 6 SAMPLES Color Contrast http://magicwebs.magicsw.com/seg/DLOSamples/Mathematics2/index.html Drag and Drop, Access Keys https://dev.opera.com/articles/accessible-drag-and-drop/example.html Access Keys, Closed Captioning http://accessiblewebsitedesignexamples.com/accessible-gallery.php#content Video Captioning http://people.opera.com/brucel/demo/video/multilingual-synergy.html FREQUENTLY ASKED QUESTIONS Q:What is WCAG 2.0? A: The Web Content Accessibility Guidelines are international accessibility standards. Section 508 is closely aligned with WCAG. Here are the WCAG 2.0 Guidelines- http://www.w3.org/TR/WCAG/tml Q: What is Section 508? A: The Section 508 Technical Standards are accessibility standards originally developed for the U.S. Federal Government. Keyboard navigation, screen reader access, and alternative text comprise the foundation of the Section 508 standards. The State of Texas requires Section 508 instructional materials. Here are the Section 508 Technical Standards- http://www.access-board.gov/sec508/standards.htm#Subpart_b
- 7. 7 Q: What are "low incidence" disabilities? A: Vision impairment, hearing impairment, and low motor ability. Q: Does accessibility only apply to students? A: No, there are three types of users in the education space: student/learner, teacher/instructor, and administrator. Students use instructional materials and assessments. Teachers manage assignments and create their own content. And administrators interact with class and student information. Q: Do we need to make different versions of our product? A: Including accessible functionality in any digital product doesn’t mean a need to make different versions for students with disabilities. By enabling a learning product to be accessed by Assistive technologies can allow students to access the content in a single version of content. Q: Do we need to change the learning product design to pass some kind of accessibility review? A: Once a product is conceptualized and designed, the UX designers establish the product navigation and information architecture as per accessibility criteria. The developers include keyboard navigation and access to assistive technology to the product or platform architecture.e content in a single version of content. Q: Are there interactions/activities that can’t be made accessible? A: While most activities can be made accessible to students using assistive technology, some activities cannot. For example, it’s possible to make a drag and drop usable by a blind student or by a student using an alternative input device, like a head mouse. However, activities that rely on spatial determinations or hand eye coordination often aren’t usable by blind students. For example, an iPad app that relies on eye/hand coordination, or a Social Studies activity that requires students to click a specific point on a map will not be accessible. In such cases, an activity’s learning objectives must be presented in an HTML document or other equivalent, and we should be prepared to offer suggestions to our customers about accommodations or modifications that will enable our students to access the educational benefits the technology provides. Exceptions must be described in any accessibility documentation. Q: What is UDL? A: Universal Design for Learning is an instructional design theory, based on research in the learning sciences, including cognitive neuroscience that guides the development of instructional materials that can accommodate individual learning differences. Q: What is Magic Software’s Development strategy on Universal Design for Learning? A: Magic Software employs the best authors, instructional designers, and UX designers in the world and many of them are familiar with the principles of Universal Design for Learning. These authors and designers may decide to apply UDL when creating content and products, or they may decide to go in another direction. Q: When licensing/producing video content, is there anything that needs to be included for accessibility? A: Be sure that all video is captioned for the hearing-impaired. Note that in many cases, alt descriptions to support blind users are needed as well.