Expected Behavior

Every field of the accessibility forms has a related tip, presented with a information icon

Current Behavior

The information icon is presented without a text

Steps to Reproduce

Possible Solution

Check the component AccessibilityHelp which manage the feedbacks for the accessibility fields.

AccessibilityHelp from '../tools/AccessibilityHelp'

<AccessibilityHelp 
  id={'short-description-help-container'}  //id of the feedback container
  name={'shortDescriptionHelpContainer'} //name of the feedback container
  error={props.error}  //[bool] accessibility resource configuration status
  tip={props.tip}  // tip message 
/>

Possible Implementation

Related issues

1.2.2

Tasks

List the tasks required to accomplish the requirement (not exhaustive)

• SYSTEM MUST include SELI's videos contents with captions (embedded or not) for all videos that student may consume. #159

• When TEACHER uploads a video content (not video-only)

  • SYSTEM MUST provide a checkbox to TEACHER marks if it is a video-only.

• IF TEACHER uploads a video content, i.e. video-only checkbox not checked

  • SYSTEM MUST provide a checkbox to TEACHER marks if the video has captions embedded.

• IF TEACHER uploads a video content without embedded captions, i.e. embedded captions checkbox not checked

  • SYSTEM MUST provide an option to TEACHER uploads captions files

• SYSTEM MUST render teacher's video content with it captions, if teacher uploads one. #159

Intent

enable people who are deaf or hard of hearing to watch synchronized media presentations. Captions provide the part of the content available via the audio track. Captions not only include dialogue, but identify who is speaking and include non-speech information conveyed through sound, including meaningful sound effects.

Examples

1. A captioned tutorial
   A video clip shows how to tie a knot. The captions read,
   "(music)
   Using rope to tie knots was an important skill
   for the likes of sailors, soldiers and woodsmen.."
   From Sample Transcript Formatting by Whit Anderson.
2. A complex legal document contains synchronized media clips for different paragraphs that show a person speaking the contents of the paragraph. Each clip is associated with its corresponding paragraph. No captions are provided for the synchronized media.
3. An instruction manual containing a description of a part and its necessary orientation is accompanied by a synchronized media clip showing the part in its correct orientation. No captions are provided for the synchronized media clip.
4. An orchestra provides captions for videos of performances. In addition to capturing dialog and lyrics verbatim, captions identify non-vocal music by title, movement, composer, and any information that will help the user comprehend the nature of the audio. For instance captions read,
   "[Orchestral Suite No. 3.2 in D major, BWV 1068, Air]
   [Johann Sebastian Bach, Composer]
   ♪ Calm melody with a slow tempo ♪"

Sufficient Techniques

Sufficient techniques are reliable ways to meet the success criteria.

• From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.
• From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.)
  There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG document, as Other Techniques below. (See also Techniques are Informative above.)

• G93
• G87

G93: Providing open (always visible) captions

The objective of this technique is to provide a way for people who are deaf or otherwise have trouble hearing the dialogue in audio visual material to be able to view the material. With this technique all of the dialogue and important sounds are embedded as text in the video track. As a result they are always visible and no special support for captioning is required by the user agent.

Example

• In order to ensure that everyone can view their online movies, even if users do not know how to turn on captions in their media player, a library association puts the captions directly into the video.
• A news organization provides open captions on all of its material

Test Procedure

1. Watch the synchronized media with closed captioning turned off.
2. Check that captions (of all dialogue and important sounds) are visible.

Expected Results

Check # 2 is true

G87: Providing closed captions using any readily available media format that has a video player that supports closed captioning

The objective of this technique is to provide a way for people who have hearing impairments or otherwise have trouble hearing the dialogue in synchronized media material to be able to view the material and see the dialogue and sounds - without requiring people who are not deaf to watch the captions. With this technique all of the dialogue and important sounds are embedded as text in a fashion that causes the text not to be visible unless the user requests it. As a result they are visible only when needed. This requires special support for captioning in the user agent.

Example

1. In order to ensure that users who are deaf can use their interactive educational materials, the college provides captions and instructions for turning on captions for all of their audio interactive educational programs.
2. The online movies at a media outlet all include captions and are provided in a format that allows embedding of closed captions.
3. Special caption files including synchronization information are provided for an existing movie. Players are available that can play the captions in a separate window on screen, synchronized with the movie window.
4. A video of a local news event has captions provided that can be played over the video or in a separate window depending on the player used.

Test Procedure

1. Turn on the closed caption feature of the media player
2. View the synchronized media content
3. Check that captions (of all dialogue and important sounds) are visible

Expected Results

Check # 3 is true

G87: Providing closed captions using any of the technology-specific techniques below (I'm just refering to h95 technique, for others see full documentation)

• H95: Using the track element to provide captions

The objective of this technique is to use the HTML5 track element to specify a captions timed text track for a video element. Caption timed text tracks contain transcription or translation of the dialogue, sound effects, relevant musical cues, and other relevant audio information, suitable for when sound is unavailable or not clearly audible.
Example
A video element for a video in the English language with an English caption track. The captions are provided in the WebVTT format.

<video poster="myvideo.png" controls>
  <source src="myvideo.mp4" srclang="en" type="video/mp4">
  <source src="myvideo.webm" srclang="fr" type="video/webm">
  <track src="myvideo_en.vtt" kind="captions" srclang="en" label="English">
  <track src="myvideo_fr.ttml" kind="captions" srclang="fr" label="French">
</video>      

Test Procedure

1. Check that the video contains a track element of kind captions in the language of the video.

Expected Results

Check # 1 is true.

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria

GLOSSARY

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

To keep consistency, should change the accessibility status icons for the same as in accessibility settings forms, with a minor modification, as in image at the right

Link added by teacher in activity content (authoring tool) are not rendering correctly.

Expected Behavior

The links added by one teacher in the authoring tool must render correctly.

Current Behavior

The links are not being rendered as links, but as texts (the tag structure appears instead).

Steps to Reproduce

Add a link in the authoring tool. Render this link.

As a teacher

1. Insert a Activity content
2. In instruction input, add a link using the "link button" of the text editor
3. Create the content
4. Publish the course

** As a student**

1. Navigate to the course and open the activity
2. The link is rendered not parsed.

SELI - Accessibility test (slide 21)

Environment

Browser: all

Possible Implementation

• As stated in issue #34, it's necessary to change the text editor component for the a11yEditor.
• And add a block type for link in the a11yEditor

Related issues

#34

When an activity is rendered, in the student side, it shows some important informations. But when the student clicks to open the activity (a modal), this important information is not presented in the modal. It can created difficulties for students with cognitive disabilities.

Expected Behavior

All the information must be presented in both of the screens.

Current Behavior

The information are only presented in the first screen.

Steps to Reproduce

1. Navigate to a course
2. Open a activity

Environment

Browser: all

Possible Solution

Add the information to both the screens as indicated in the image
See #51

Expected Behavior

Long description field should show for complex images when editing accessibility configuration

Current Behavior

Long description field is hide

Steps to Reproduce

1. Configure accessibility of an image
2. Check complex image options and fill up long and short description
3. Save and close
4. Select to configure accessibility for the same image
5. Accessibility form is loaded without long description field

Possible Solution

Possible Implementation

Related issues

Expected Behavior

When user mark that video hasn't audio-description embedded, the system enabled the upload button

This was working properly before please have a look at change history of the code.
How it work before

1. Initial state: Not embedded and audiodescription is required
   Note that teacher needs to check if audiodescription is required or not
   
2. Embedded
   Note that everything else are disabled and accessibility resource is valid
   
3. Audio description is not required, accessibility resource is valid
   

See working the code

NOTE: this was a simplified version for the prototype version of SELI.
To fully attend WCAG requirement, see requirements #11 #12 #13

Current Behavior

When user mark that video hasn't audio-description embedded, the system enabled the upload button

Possible Solution

Please refer to task section of requirement #11

When teacher upload a complex image, long description field is enabled, so teacher can inform a image caption.
Then, teacher can select if caption will be positioned above or bellow the image.

Expected Behavior

It was working before

Current Behavior

Steps to Reproduce

1. Select Complex image
2. Long description field and caption position should enable

Possible Solution

Possible Implementation

Related issues

Expected Behavior

After image content is created, user must have the option to configure the accessibility resources immediately.

Current Behavior

Only the option to configure the accessibility later is enabled for user.

Steps to Reproduce

1. Upload a image file
2. Give a title and optionally a external link and description
3. Click the button "create content"

Possible Solution

Possible Implementation

Issue reference

#2 #6

Expected Behavior

Current Behavior

Possible Implementation

For audio-only (no video) sign language is not required.
Please refer to Tasks in requirement #8

Expected Behavior

• A button activates functionality (e.g., shows or hides content, toggles a state on or off).
• A link is intend to navigate to new content.

Current Behavior

Above list is not an exhaustive, but meant to help you understand the problem. I'd suggest that when working in some existent code, to search for problems like this.

• Course Preview button
  

• Course duration button
  

• Course Syllabus button
  

• Course overview
  

• Ordered list
  

• Some cards are rendered as a button.
  

• Video Content
  

• Sliders
  

Steps to Reproduce

• For each button in a page, check if the button activates functionality

Environment

Browser: all

Possible Implementation

• Slider using react component
• Link

<a href="#content">TEXT DESCRIPTION</a>

or, using react component

<Link href="#content" onClick={preventDefault} className={classes.link}>
      TEXT DESCRIPTION
</Link>

NOTE:
Custom widgets are interactive interface components designed to meet unique UX needs. They are created by adding functionality to native widgets or to non-interactive components such as

A button activates functionality (e.g., shows or hides content, toggles a state on or off).

A link navigates to new content.

• Don’t custom style links
• Use material-ui

Button Style

Check https://uxdesign.cc/ui-cheat-sheets-buttons-7329ed9d6112

Button Hierarchy and Emphasis

From material-ui

An app can show more than one button in a layout at a time, so a high-emphasis button can be accompanied by medium- and low-emphasis buttons that perform less important actions.
When using multiple buttons, ensure the available state of one button doesn’t look like the disabled state of another.
In a bottom bar, when using multiple buttons, indicate the more important action by placing it in a contained button (next to a text button).
Avoid using two contained buttons next to one another if they don’t have the same fill color.

Upload buttons

See live demo using react components
https://codesandbox.io/s/upload-form-4vtjg?file=/demo.js

Button preceded by an icon that represents the source type. The button label (“what is going to be selected?”) should be:

• “Upload syllabus”
• “Upload profile photo”
• Upload a PDF / Image / Video file

Description:

• Type specifiers
• Size limitation
• Any other in formation required for select the correct file

After file is selected, replace the icon by a preview of the file (ie: the image selected). In case isn’t possible to a preview, like in a pdf file, replace by an icon/image that represent the type of file

1.2.1

Tasks

List the tasks required to accomplish the requirement (not exhaustive)

• DEVELOPERS MUST include video-only contents with it text alternative AND/OR audio alternative #159

All contents not created by users (e.g. SELI "about" section text, buttons, fields) that STUDENT could consume

• When TEACHER uploads a video content

  • SYSTEM MUST provide a checkbox to TEACHER marks if it is a video-only.

• IF TEACHER uploads a video-only content, i.e. checks the video-only checkbox

  • SYSTEM MUST provide:
    • an option to TEACHER write/paste a text transcription; OR
    • an option to TEACHER uploads an audio file (❗ or a .vtt file), as an an audio-description.

• DEVELOPERS MUST render teacher's content with it respective text alternative, if teacher configured one. #159

Intent

Alternatives for time-based media that are text based make information accessible because text can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user. In the future, text could also be translated into symbols, sign language or simpler forms of the language (future).

The purpose of the transcript is to provide an equivalent to what is presented visually. For prerecorded video content, authors have the option to provide an audio track.

The purpose of the audio alternative is to be an equivalent to the video. This makes it possible for users with and without vision impairment to review content simultaneously. The approach can also make it easier for those with cognitive, language and learning disabilities to understand the content because it would provide parallel presentation.

Examples

1. An animation that illustrates how a car engine works
   An animation shows how a car engine works. There is no audio and the animation is part of a tutorial that describes how an engine works. Since the text of the tutorial already provides a full explanation, the media is an alternative for text and the text alternative includes only a brief description of the animation and refers to the tutorial text for more information.
2. A video-only file with an audio track
   A silent movie includes an audio track which includes a description of the action in the video.

Sufficient Techniques

Sufficient techniques are reliable ways to meet the success criteria.

• From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.
• From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.)
  There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG document, as Other Techniques below. (See also Techniques are Informative above.)

• G158 (meets #14)
• G166

G158: Providing an alternative for time-based media for audio-only content

In order to present the same information in accessible form, this technique involves creating a document that tells the same story and presents the same information as the prerecorded video-only content. In this technique, the document serves as a long description for the content and includes all of the important information as well as descriptions of scenery, actions, expressions, etc. that are part of the presentation

Example
An animation shows how to assemble a woodworking project. There is no audio, but the animation includes a series of numbers to represent each step in the process as well as arrows and picture-in-picture highlights illustrating how the assembly is completed. It also includes short outtake animations illustrating what will happen if assembly is done incorrectly. A text alternative that identifies the video-only content reads, "Breadbox assembly video (text description follows)," and the text description of the video includes a full text description of each step in the video.

Test Procedure

1. View the video-only content while referring to the alternative for time-based media.
2. Check that the dialogue in the transcript matches the dialogue and information presented in the video-only presentation.
3. If the video includes multiple people or characters, check that the transcript identifies which person or character is associated with each action described.
4. Check that at least one of the following is true:

• The transcript itself can be programmatically determined from the text alternative for the video-only content
• The transcript is referred to from the programmatically determined text alternative for the video-only content

5. If the alternate version(s) are on a separate page, check for the availability of link(s) to allow the user to get to the other versions.

Expected Results

All of the above checks are true.

G166: Providing audio that describes the important video content and describing it as such

Video-only content is inaccessible to people who are blind and to some who have low vision. Therefore, it is important for them to have an audio alternative. One way of doing this is to provide an audio track describing the information in the video. The audio should be a common audio format used on the internet, such as MP3.

Example
A Web page has a link to a video-only presentation of a spaceship landing on Mars. The link to the video is a picture of a spaceship. Near the video is a link to an audio file of a person describing the video. This would look something like the following code example in HTML.

 <a href="../video/marslanding.mp4"><img src="../images/spaceship.jpg" 
                alt="Mars landing, video-only" width="193" height="255"/></a>
                <br />
                <a href="Mars_landing_audio.mp3">Audio description of "Mars Landing"</a>

Test Procedure

For a Web page that contains video-only content:

1. Check that there is link to an audio alternative which describes the contents of the video immediately before or after the video-only content.

Expected Results

Check #1 is true

Advisory Techniques

Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content.
Advisory techniques are not designated as sufficient techniques for various reasons such as:

• they may not be sufficient to meet the full requirements of the success criteria;
• they may be based on technology that is not yet stable;
• they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet);
• they may not be testable;
• in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;
• they may not address the success criterion itself, and instead provide related accessibility benefits.
  Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of users' needs.

H96: Using the track element to provide audio descriptions

The objective of this technique is to use the HTML5 track element to specify a descriptions timed text track for a video element. Audio description timed text tracks contain textual descriptions of the video component of the media resource, intended for audio synthesis when the visual component is obscured, unavailable, or not usable. The user agent makes the cues available to the user in a non-visual fashion, for instance, by synthesizing them into speech.

❗ As of February 2019 when this Advisory technique was last reviewed by the Working Group, there is no native support in user agents for this technique. However, support is available via JavaScript polyfills.

Example
A video element for a video in the English language. The audio descriptions are provided in the WebVTT format.

<video poster="myvideo.png" controls>
  <source src="myvideo.mp4" srclang="en" type="video/mp4">
  <track src="myvideo_en.vtt" kind="descriptions" srclang="en" label="English">
</video>

Test Procedure

For each video element used to play a video:

1. Check that the video contains a track element of kind descriptions in the language of the video.

Expected Results

Check #1 is true

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria
• aria-describedby for longer text alternative
• Transcript Examples

GLOSSARY

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Expected Behavior

After create a content system must add it to "content area"

Current Behavior

If user clicks the "x" button of the accessibility configuration step modal, the previous created content is lost.

Steps to Reproduce

1. Create a content that has accessibility resources to configure (e.g.: video, image, audio)
2. Click the button "x" on the top of the modal
   

Possible Solution

This kind of modal, where it's expected user select between options, must not have a close button ('x')

Possible Implementation

Instead of 3-steps to create and configure content, keep in one step.
If have any doubt on how to code this, I can help. I've done this before but it was lost in old Mateo's merges

https://docs.google.com/presentation/d/1C5LxvjcMMPaNZ-8XGr0Lv6x0wapgcenQubL_U9V9fhw/edit#slide=id.g756484533f_1_941

Index

1. Accessibility Validation
   1. Accessibility Validation Filter
   2. Accessibility Validation Progress
   3. Accessibility Configuration
   4. Content Area
2. Report
   1. Full accessible course
   2. Without inclusion goal
   3. With inclusion goal
      1. Inclusion Goal is achieved

Demo

Accessibility Validation

During course creation, teacher will be guided by system on web content accessibility, giving teacher the opportunity to add contents with accessibility resources.

• Each type of content of the Program step has a set of accessibility resources.
• Optionally, teacher can configure the accessibility resources. The resources status should be:
  • well configured: teacher selects an option that is accessible
  • misconfigured: teacher selects an option that is not accessible
  • not configured: teacher does not configured the accessibility resource

Accessibility Validation Filter

This tool has the purpose to help teacher visualize accessibility problems by impairments.

• Update the list of impairments in the select component as below

• The Accessibility Validation Filter will be loaded filtered by the selection of Audience[InclusionGoal] (#145)
• At any time, teacher can change the filter of Accessibility Validation Filter in the program step. This will not change the selection of Audience[InclusionGoal]

Accessibility Validation Progress

The overall accessibility progress of a given component is presented in a Circular Progress component

• component: material-UI Circular Progress with label
• label: "c/t", where t is the total of accessibility resources of the component and c is the total of well configured resources of the component.
• color progress: a scale of orange to green

Accessibility Configuration

• The set of accessibility resources related to the selection of Audience[InclusionGoal] will be presented with "(Required for Inclusion)" in their the visible label.
  
  
• The set of accessibility resources NOT related to the selection of Audience[InclusionGoal] will be presented with in their original label.
  
• At the top of each Accessibility Configuration form show the message:
  Fields presented as Required for Inclusion are accessibility resources that are necessary to achieve the course inclusion goal defined in Audience Step
• Use the accessibility progress component (specified above) to present the overall accessibility status
• Use feedback component (#46) to present the status of each resource.
  • well configured: presents the accessible status
  • misconfigured and not configured: presents the inaccessible status and the error message
    

Content Area

• For each content on Content Area, system shows the accessibility progress component (specified above) to present the overall accessibility status

• The overall value presented is conditional to the Accessibility Validation Filter.
  For example, supposing that a component has been configured 3 resources of a total of 6 resources. If all impairments is selected in Accessibility Validation Filter, the overall accessibility status will be 3/6. But if teacher filer by Visual impairments and in this hypothetical component only 2 of the 6 resources is necessary for Visual accessibility and 1 is configured, thus the overall presented will be 1/2

Report

Before publish the course, teacher could see an accessibility report for the entire course.

• If teacher does not select any Inclusion Goal at Audience Step, then Publish will not be conditioned to accessibility result.
• If teacher selected any Inclusion Goal at Audience Step, system must enable Publish the course only when all accessibility resources are well configured for all impairment group selected.
• If teacher click on a Topic Name, system should ask if teacher wants to go to the topic ( Program Step) to fix the accessibility problems

Full accessible course

• If teacher well configure all accessibility resources for all impairment groups, Report should present a message that the course is fully accessible
  

Without Inclusion Goal

• Report will present the overall accessibility status for each impairment group (in percentage)
• Report will present the accessibility status for each topic/unit by impairment group (in percentage)

with Inclusion Goal

• Report will present the overall accessibility status of the Inclusion Goal (in percentage)
• Report will present the overall number of accessibility resources well configured (Done card)
• Report will present the overall number of accessibility resources not configured (TO-DO card)
• Report will present the overall number of accessibility resources misconfigured (Not Accessible card)
• Report will present the overall accessibility status for each impairment group of the Inclusion Goal (in percentage)
• Report will present the accessibility status for each topic/unit by impairment group of the Inclusion Goal (in percentage)

Inclusion Goal is achieved

• When teacher finish to well configure all accessibility resources for the Inclusion Goal, Report should suggest to Teacher to review the accessibility of other groups. Only if the inclusion goal do not include all impairment groups

• Report will present the overall accessibility status of the Inclusion Goal (100% in percentage) and a message about the achievement

• Report will present the overall accessibility status for each impairment group not included in Inclusion Goal (in percentage)

• Report will present the accessibility status for each topic/unit by impairment group not included in Inclusion Goal (in percentage)

Wire frame

Accessibility feedback given for each content on Content Area

Expected Behavior

User can use tab to navigate in and away from text editor.

Current Behavior

User can use tab to navigate to text editor, but can't navigate away using tab.

Steps to Reproduce

1. As a student, start an Activity in any course.
2. Navigate to text editor using TAB key
3. Use TAB key to navigate away from text editor (failed)

https://docs.google.com/presentation/d/1OBRtT9S3NZWK2bq9wvEzXLxcoQMxMC_CesAsUgqkUww/edit#slide=id.g65604c07eb_1_510

Environment

Debian OS
Browser: Chrome

Possible Implementation

Use a11yEditor instead, styleEditor

https://gitlab.com/ecureuill/seli/-/blob/master/SELI-Platform/imports/components/tools/a11yEditor.js#L58

Use the a11yTextEditor

Related issues

Expected Behavior

Quiz with time constraint should close after time end.

Current Behavior

Timer is not starting. Visual feedback of time keep the same and quiz never close.

Steps to Reproduce

As a student

1. Start a quiz with time constraint
2. Wait for quiz to automatically close
   1. Textual feedback of time never change, e.g., as time goes, it keep showing "00:02:00"
   2. As time run out, quiz didn't close

Environment

Debian SO
Chrome

Expected Behavior

When open the accessibility configuration, should load previous settings

Current Behavior

When open the accessibility configuration, the long description field's content are not being loaded.

Steps to Reproduce

1. Create a video/image content
2. Choose to configure accessibility
3. Insert a text content in the long description field (text alternative second field)
4. Save
5. Choose to configure accessibility
6. Form is opened without the long description content.

Note: In both images, the text presented are the placehold

Possible Solution

On a11yEditor

• props editorData: keyname of the localstorage
• The content of the a11yEditor should be saved as a raw.

On line 666, I let it prepared to get content from localstorage
NOTE: Need to change for the correct database

// a function to only read localstorage **at first render**
const initialRaw = () => { localStorage.getItem(props.editorData) || ''; };
const [inputRaw, setInputRaw] = React.useState(initialRaw);

It is pending that at first render the DrafJs uses the raw to be instantiated. Something like this...

// const contentState = convertFromRaw(inputRaw);
// const [editorState, setEditorState] = React.useState(DraftJS.EditorState.createWithContent(inputRaw));

On line 746, it's saving content to localstorage, on every change of the content
My idea was that when user choosed to save all the "accessibility configuration", the backend function look for this "temporally storage" to persist the content

let raw = DraftJS.convertToRaw(currentContent);
setOutputRaw(raw);
localStorage.setItem('editorData', JSON.stringify(raw));

On line 937 there's the option to save content on user request (CTRL+S for instance)

if (command === 'myeditor-save') {
  // TODO: Perform a request to save your contents, set a new `editorState`, etc.
  return 'handled';
}

On a11yLongDescription

Is missing pass the props.editorData

<CaptionEditor id={'long-description-input'}
  name={props.name}
  label={props.label}
  aria-describedby='long-description-help-container'
  placeholder={props.placeholder}
  value={props.value} 
  onChange={props.handleOnChange}
  error={props.error}
  required={props.required}
  handleerror={props.handleerror}
//HERE
  editorData={props.editorData}
/>

And every component that used the a11yLongDescription should pass form editorData the correct localstorage keyname (or other database)

For instance ImageAccessibilityForm

<A11YLongDescription
	editorData='Caption'
/>

Possible Implementation

Related issues

1.1.1

For non-text content that is a control or accepts user input , such as images used as submit buttons, image maps or complex animations, a name is provided to describe the purpose of the non-text content so that the person at least knows what the non-text content is and why it is there.

Scenario: Objects

• Use aria-label attribute to provide the text label for an object, such as a button.
  When a screen reader encounters the object, the aria-label text is read so that the user will know what it is.
  • ARIA9: Using aria-labelledby to concatenate a label from several text nodes

<div role="navigation" aria-label="Primary">
<ul><li>...a list of links here ...</li></ul> </div>
<div role="navigation" aria-label="Secondary">
<ul><li>...a list of links here ...</li> </ul></div>

<div role="region" aria-label="weather portlet"> 
...
</div>

<div role="math" aria-label="6 divided by 4 equals 1.5">
  <math xmlns="https://www.w3.org/1998/Math/MathML">
    <mfrac>
      <mn>6</mn>
      <mn>4</mn>
    </mfrac>
    <mo>=</mo>
    <mn>1.5</mn>
  </math>
</div>

Test Procedure

For each element where a aria-label attribute is present.

1. Examine whether the text description accurately labels the object or provides a description of its purpose or provides equivalent information.

Scenario: Links

• Providing link text that describes the purpose of a link for anchor elements. The description lets a user distinguish this link from other links in the Web page and helps the user determine whether to follow the link. The URI of the destination is generally not sufficiently descriptive.
  Test Procedure
  For each link in the content that uses this technique:

1. Check that text or a text alternative for non-text content is included in the a element
2. If an img element is the only content of the a element, check that its text alternative describes the purpose of the link
3. If the a element contains one or more img element(s) and the text alternative of the img element(s) is empty, check that the text of the link describes the purpose of the link
4. If the a element only contains text, check that the text describes the purpose of the link

Scenario: Images as submit buttons

• Use alt attributes on images used as submit buttons
  The alt attribute of the input element is used to provide a functional label. This label indicates the button's function, but does not attempt to describe the image. The label is especially important if there are multiple submit buttons on the page that each lead to different results.

<form action="http://example.com/prog/text-read" method="post">
     <input type="image" name="submit-publish" src="button1.gif" alt="Save and Publish" />
   <input type="image" name="submit-save" src="button2.gif" alt="Save" />
</form>

Test Procedure

For all input elements that have a type attribute value of "image"

1. Check for the presence of an alt attribute.
2. Check that the alt attribute indicates the button's function.

Scenario: Form controls

• Using label elements to associate text labels with *form controls. A label is attached to a specific form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control. The id attribute may have the same value as the name attribute, but both must be provided, and the id must be unique in the Web page.
• Using the title attribute to identify form controls when the label element cannot be used. Use the title attribute to provide an accessible name for form controls when the visual design does not include text on the screen that can be associated with the control as a label. User agents, including assistive technology, can speak the title attribute.

NOTE
Elements that use explicitly associated labels are:

• input type="text"
• input type="checkbox"
• input type="radio"
• input type="file"
• input type="password"
• textarea
• select
  The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button).
• Submit and Reset buttons ( input type="submit" or input type="reset")
• Image buttons ( input type="image")
• Hidden input fields ( input type="hidden")
• Script buttons (button elements or )

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

<input type="checkbox" id="markuplang" name="computerskills" checked="checked">
<label for="markuplang">HTML</label>

 <h1>Donut Selection</h1>

<p>Choose the type of donut(s) you would like then select 
   the "purchase donuts" button.</p>

<form action="http://example.com/donut" method="post">
<p>
  <input type="radio" name="flavor" id="choc" value="chocolate" />
    <label for="choc">Chocolate</label><br/>
  <input type="radio" name="flavor" id="cream" value="cream"/>
    <label for="cream">Cream Filled</label><br/>
  <input type="radio" name="flavor" id="honey" value="honey"/>
    <label for="honey">Honey Glazed</label><br/>
  <input type="submit" value="Purchase Donuts"/>
</p>
</form>

<label for="searchTerm">Search for:</label>
<input id="searchTerm" type="text" size="30" value="" name="searchTerm">
<select title="Search in" id="scope">
…
</select>

<fieldset><legend>Phone number</legend>
   <input id="areaCode" name="areaCode" title="Area Code" 
type="text" size="3" value="" >
   <input id="exchange" name="exchange" title="First three digits of phone number" 
type="text" size="3" value="" >
   <input id="lastDigits" name="lastDigits" title="Last four digits of phone number" 
type="text" size="4" value="" >
</fieldset> 

<input type="text" title="Type search term here"/> <input type="submit" value="Search"/>

Note: A data table of form controls needs to associate each control with the column and row headers for that cell. Without a title (or off-screen label) it is difficult for non-visual users to pause and interrogate for corresponding row or column header values using their assistive technology while tabbing through the form.
For example, a survey form has four column headers in first row: Question, Agree, Undecided, Disagree. Each following row contains a question and a radio button in each cell corresponding to answer choice in the three columns. The title attribute for every radio button contains the information necessary to identify the control.

Test Procedure

For all input elements of type text, file or password, for all textareas and for all select elements in the Web page:

1. Check that there is a label element that identifies the purpose of the control before the input, textarea, or select element
2. Check that the for attribute of the label element matches the id of the input, textarea, or select element
3. Check that the label element is visible. (

For all input elements of type checkbox or radio in the Web page::

1. Check that there is a label element that identifies the purpose of the control after the input element
2. Check that the for attribute of the label element matches the id of the input element
3. Check that the label element is visible.

For all form controls that are not associated with a label element:

1. Check that the control has a title attribute
2. Check that the purpose of the form control is clear to users who can see the control.
3. Check that the title attribute identifies the purpose of the control and that it matches the apparent visual purpose.

Resources

https://developers.google.com/web/fundamentals/accessibility/semantics-aria/aria-labels-and-relationships?hl=pt-br

1.2.7

• To meet this requirement, MUST implement #11 or #12 using G8 technique

Referenced Requirements

1.2.3(#11), 1.2.5(#12), and 1.2.8 overlap somewhat with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in Success Criterion 1.2.3, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under Success Criterion 1.2.5 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.3, otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they must provide an extended text description. This is an additional requirement if both 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, however, by providing a text description, and the 1.2.5 requirement for an audio description was met, then 1.2.8 does not add new requirements.

General description

Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media.

Intent

provide people who are blind or visually impaired access to a synchronized media presentation beyond that which can be provided by standard audio description. This is done by periodically freezing the synchronized media presentation and playing additional audio description. The synchronized media presentation is then resumed.

Because it disrupts viewing for those who do not need the additional description, techniques that allow you to turn the feature on and off are often provided. Alternately, versions with and without the additional description can be provided

information_source For 1.2.3(#11), 1.2.5(#12) , and 1.2.7(#13), if all of the information in the video track is already provided in the audio track, no audio description is necessary.

Examples

1.Video of a lecture. A physics professor is giving a lecture. He makes freehand sketches on the whiteboard, speaking rapidly as he draws. As soon as he has finished discussing one problem, he erases the drawing and makes another sketch while continuing to speak and gesture with his other hand. The video is paused between problems, and extended audio description of the professor's drawings and gestures is provided; the video is then resumed.

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria

GLOSSARY

• SELI's content: all contents not created by users (e.g. seli "about" section text)

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Expected Behavior

After audio content is created, user must have the option to configure the accessibility resources immediately.

Current Behavior

Only the option to configure the accessibility later is enabled for user.

Steps to Reproduce

1. Upload an audio file
2. Give a title and optionally a external link and description
3. Click the button "create content"

Possible Solution

User story

As a STUDENT WITH SPECIAL NEEDS I want to extend Quiz time So that I can finish the activity

ACCEPTANCE CRITERIA

• Scenario: Alert in Quiz with time constraint
  GIVEN I'm doing a quiz
  WHEN the system alert me that the time is almost out AND I have the option to extend time AND I click the option to extend time
  THEN quiz time is extended

• Scenario: Extra time option for a Quiz with time constraint
  GIVEN I select to start a quiz
  WHEN I click the option to extend time
  THEN quiz time is extended

• Scenario: No time option for a Quiz with time constraint
  GIVEN I select to start a quiz
  WHEN I click the option to disable time
  THEN quiz time constraint is disabled.

NOTES

• extra-time and no-time options depends on teacher configuration of quiz (see #40)
• extra-time and no-time could be presented at the confirmation modal (First modal after user select to start the quiz)
  • Cancel button
  • Start | Start with extended time | Start with no time constraint
    first page of quiz

Glossary

STUDENT WITH SPECIAL NEEDS:

• People with physical disabilities often need more time to react, to type and to complete activities.
• People with low vision need more time to locate things on screen and to read.
• People who are blind and using screen readers may need more time to understand screen layouts, to find information and to operate controls.
• People who have cognitive or language limitations need more time to read and to understand.
• People who are deaf and communicate in sign language may need more time to read information printed in text (which may be a second language for some).
• People with reading disabilities, cognitive limitations, and learning disabilities who may need more time to read or comprehend information can have additional time to read the information by pausing the content.

Resources

• Check Audience tab in Requisitos Spreadsheet.
• Filter by 2.2.1 and 2.2.3 for a list of disability profiles affected by this feature
• WCAG 2.2.1
• WCAG 2.2.3

[Optional] Developer team add your technical tasks here

• [ ]
• [ ]

[Optional] Tester team, add your test procedures here

It's necessary to adequate the RadioGroup react component to behaviour like a input radio native widget to provide accessibility support.

Expected Behavior

• Every radio group must provide a descriptive text informing what it is about.
• Every option must provide a label.

Current Behavior

The radio groups does not provide the adequate description for the accessibility support nor behaviour as a native radio

Steps to Reproduce

• Navigate to a course
• Start a quiz and use a Screen reader.

Environment

Browser: all

Possible Solution

Fix the react component as suggested

• Add aria tag in RadioGroup
• Add label attribute in FormControlLabel
• Add control attribute to option render as a native component

   <RadioGroup aria-labelledby="rgtl1" name="question" value={value} onChange={handleChange}>

         <h3 id="rgtl1">Question</h3>

         <FormControlLabel value="option-one" control={<Radio />} label="Option 1" />

         <FormControlLabel value="option-two" control={<Radio />} label="Option 2" />

         <FormControlLabel value="option-three" control={<Radio />} label="Option 3" />

       </RadioGroup

This is a "not-end" requirement. What I want to mean is that this should be considered for any new page you create that Student can access. Also should correct the old pages.

I will use the label Feature Design Notes to this cases

wcag: 3.3.4
For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

• Reversible
  Submissions are reversible.
• Checked
  Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed
  A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Scenario: No exception

In this scenario, all forms with no exception, must apply to above rule

For Web pages that require the user to submit information, at least one of the following is true:

• Reversible
  Submissions are reversible.
• Checked
  Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed

• Follows the same techniques listed bellow

Scenario: If an application causes a legal transaction to occur, such as making a purchase or submitting an income tax return

• Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request
• Providing the ability for the user to review and correct answers before submitting
• Providing a checkbox in addition to a submit button
  This is important when the nature of the transaction is such that it may not be reversible if input errors are subsequently discovered or when the result of an action is that data is deleted. The author provides a checkbox that is not selected when the page loads, with a label like "I confirm that the input is correct and am ready to submit" or "I confirm that I wish to delete this data". The checkbox should be located near the submit button to help the user notice it during the submission process. If the checkbox is not selected when the form is submitted, the input is rejected and the user is prompted to review their entry, select the checkbox, and resubmit. Only if the checkbox is selected will the input be accepted and the transaction processed. This checkbox helps to guard against the consequences of an accidental form submission, and also serves to prompt the user to be sure they have entered accurate data. This is more secure than simply putting a label on the submit button like "input is correct, submit". Providing the checkbox as a separate control from the submit button forces the user to "double-check", as they must both select the checkbox and activate the submit button for the transaction to proceed. As such, this is a mechanism for reviewing, confirming, and correcting information before finalizing the submission.

Scenario: If an action causes information to be deleted

• Providing the ability to recover deleted information
  One approach is to delay deleting the data by merely marking it for deletion or moving it to a holding area (such as a trash can) and waiting some period of time before actually deleting it. During this time period, the user can request that the data be restored or can retrieve it from the holding area. Another approach is to record all delete transactions in such a way that data can be restored if requested by the user, such as in the edit history stored by wikis and source control applications.The retrievable information that is stored should be that which would be needed to correct the transaction.

• Requesting confirmation to continue with selected action

• Providing a checkbox in addition to a submit button

Scenario: If the Web page includes a testing application:

• Providing the ability for the user to review and correct answers before submitting
• Requesting confirmation to continue with selected action
  Use this technique in situations where the action can not be undone after it has been followed through. This will help users avoid submitting a form or deleting data by mistake. The request for confirmation should inform the user of the action that was selected and the consequences of continuing with the action.

Example

• A testing application provides multiple pages of questions. At any time, the user can choose to return to previously completed sections to review and change answers. A final page is displayed providing buttons to either submit the test answers or review answers.
• An online banking application provides multiple steps to complete a transfer of funds between accounts. A summary of the transaction is provided showing the from and to accounts and the transfer amount. The user can select a button to either complete the transaction or cancel it.

🪲 Test Procedures

1. For Web pages that cause
   1. legal commitments
   2. financial transactions
   3. modify or delete user-controllable data in data storage systems
   4. submit user test responses,
2. Check that at least on of the follwing is true:
   1. Submissions are reversible.
   2. Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
   3. A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Expected Results: 2 is true.

Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request

1. Check that the Web page describes the time period to cancel or change an order.
2. Check that the Web page describes the process for canceling or changing an order.

Expected Results: all are true.

Review and correct before submit

In a testing application or one that causes financial or legal transactions to occur and that also collects data from users in multiple steps:

1. Check that the user is prompted to review and confirm data.
2. If user data are collected in multiple steps, the user is allowed to return to previous steps to review and change data.
3. Determine if a summary of all data input by the user is provided before the transaction is committed and a method is provided to correct errors if necessary.

Expected Results: 2 or 3 is true

Checkbox

For user input pages that cause irreversible transactions to occur:

1. Check that a checkbox indicating user confirmation of the input or action is provided in addition to the submit button.
2. Check that if the checkbox is not selected when the form is submitted, the input is rejected and the user is prompted to review their entry, select the checkbox, and resubmit.
   1. The form is not erased.

Expected Results: all are true.

Deletion

1. Identify functionality that allows deleting content
2. Delete content and attempt to recover it.
3. Check if deleted information can be recovered.

Expected Results: 3 is true.

1. Initiate the action that can not be reversed or changed.
2. Check that a request to confirm the selected action is presented.
3. Check that the action can be confirmed and canceled.

Expected Results: Checks 2 and 3 are true

Confirmation before continue

1. Initiate the action that can not be reversed or changed.
2. Check that a request to confirm the selected action is presented.
3. Check that the action can be confirmed and canceled.

Expected Results: Checks 2 and 3 are true

👥 Benefits

Providing safeguards to avoid serious consequences resulting from mistakes helps users with all disabilities who may be more likely to make mistakes.

• Main SELI-Platform
• Others SELI-Platform: [ current page ]

for instance
SELI-Platform: Subscription
SELI-Platform: Meteor Course

Student Profile

• Student can select category of abilities which he/she are within :

  • Cognitive Disabilities
  • Diversity of abilities (here is the elderly subgroup)
  • Hearing disabilities
  • Visual disabilities

• Student can select some default accessibility preferences for courses. Some examples above:

  • captions show on for default
  • use extra time when available in quiz/activities
  • remove time when available in quiz/activities

• Student can select default accessibility preferences for SELI Courses page accessibility filter. The filter will be active by default in this case.

  • Show only fully accessible courses
  • Show partially and fully accessible courses
  • Show only fully Cognitive accessible courses
  • Show partially and fully Cognitive accessible courses
  • Show only fully Visual accessible courses
  • Show partially and fully Visual accessible courses
  • Show only fully Hearing accessible courses
  • Show partially and fully Hearing accessible courses

Course

[ ] Base on student profile, system should automatically load course contents with the accessibilty resources preferences activated (if the course has the accessibility resource configured by teacher).

For instance

As a user with COGNITIVE DISABILITIES and option remove time when available in quiz/activities enabled in profile
WHEN starting a "quiz with time constraint configured to have no-time by teacher"
THEN system should start the quiz without time constraint

Expected Behavior

Teacher must select the type of the image, so system could enable the field of short and long description correctly.

It was working properly before

1. Initial state: Informative image only short description enabled
   

2. Decorative image: No accessibility resources required
   

3. Text: Short description
   

4. Complex: short and long description
   

Current Behavior

Steps to Reproduce

1. Select to configure image accessibility for the first time
2. Don't select any type of image options
3. Write a short description
4. Save

Possible Solution

Possible Implementation

Related issues

1.2.5

• To meet this requirement, MUST implement #11 using one of techniques bellow:
  • G78
  • G173
  • G8 (meets #13 too)
  • G203

Referenced Requirements

1.2.3(#11), 1.2.5, and 1.2.8(#13) overlap somewhat with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in Success Criterion 1.2.3, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under Success Criterion 1.2.5 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.3, otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they must provide an extended text description. This is an additional requirement if both 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, however, by providing a text description, and the 1.2.5 requirement for an audio description was met, then 1.2.8 does not add new requirements.

General description

Audio description is provided for all prerecorded video content in synchronized media.

information_source For 1.2.3(#11), 1.2.5(#12) , and 1.2.7(#13), if all of the information in the video track is already provided in the audio track, no audio description is necessary.

Intent

The intent of this Success Criterion is to provide people who are blind or visually impaired access to the visual information in a synchronized media presentation. The audio description augments the audio portion of the presentation with the information needed when the video portion is not available. During existing pauses in dialogue, audio description provides information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main sound track.

Examples

A movie with audio description.
Describer: A title, "Teaching Evolution Case Studies. Bonnie Chen." A teacher shows photographs of birds with long, thin beaks.
Bonnie Chen: "These photos were all taken at the Everglades."
Describer: The teacher hands each student two flat, thin wooden sticks.
Bonnie Chen: "Today you will pretend to be a species of wading bird that has a beak like this."
Describer: The teacher holds two of the sticks to her mouth making the shape of a beak.
Transcript of audio based on the first few minutes of " Teaching Evolution Case Studies, Bonnie Chen" (copyright WGBH and Clear Blue Sky Productions, Inc.)

Expected Behavior

Validation status should be calculated when accessibility form is opened to edit previous configuration

Current Behavior

Validation status is not calculated

Steps to Reproduce

1. Configure accessibility for image
2. Save
3. Select to configure accessibility for the same image
4. Form is opened with wrong accessibility status

Possible Implementation

Instead of load isA11y variable from database, try to call the function to calculate it.
Also, check if isA11y is being persisted correctly.

Related issues

Expected Behavior

When user mark that video has NOT captions embedded, the system enables the upload button

Current Behavior

When user mark that video has captions embedded, the system enables the upload button

Steps to Reproduce

Possible Solution

If teacher checks that video has embedded video, this accessibility resource is valid.
If teacher checks that video has not embedded video, this accessibility resource isn't valid and system enables the upload button. Them, if teacher uploads an valid caption, this accessibility resource is valid.
Please, Refer Tasks section of requirement #10

Possible Implementation

Expected Behavior

Current Behavior

Possible Implementation

Try this

.a11yEditor-root {
  background: #fff;
  border: 1px solid #ddd;
  
  padding: 0px;
  max-height: 300px;
  width: 100%;
}
.a11yEditor-controls {
  margin: 0 5px 5px 5px;!important
  user-select: none;
}

.a11yEditor-styleButton{
  color: #999!important;
  cursor: pointer!important;
  display: inline-block!important;
  padding: 2px!important;
  max-width: fit-content!important;
  max-height: 24px!important;
  border: none!important;
  margin-right: 16px!important;
}

.a11yEditor-activeButton {
  color: #5890ff!important;
}

.a11yEditor-editor {
  border-color: rgba(0, 0, 0, 0.23);
  cursor: text;
  font-size: 16px;
  top: -5px;
  left: 0;
  right: 0;
  bottom: 0;
  margin: 0;
  padding: 0;
  transition: padding-left 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms,border-color 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms,border-width 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms;
  border-style: solid;
  border-width: 1px;
  border-radius: 4px;
}

.a11yEditor-label{
  width: fit-content;
  user-select: none;
  border: none;

  /*root*/
  transform-origin: top left;
  display: block;
  /*animated*/
  transition: color 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms,transform 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms;
  /*outlined*/
  z-index: 1;
  transform: translate(14px, 20px) scale(1);
  pointer-events: none;
}

.a11yEditor-labelShrink {
    transform: translate(14px, -10px) scale(0.75);
    background-color: var(--white);
}

.a11yEditor-hidePlaceholder .public-DraftEditorPlaceholder-root {
  display: none;
}

.a11yEditor-editor .public-DraftEditorPlaceholder-root {
  margin-top: 0px;
  margin-left: 14px;
  user-select: none;
  opacity: 0.3;
  position: absolute;
}

.a11yEditor-editor .public-DraftEditor-content{
  min-height: 50px;
  max-height: 100px;
  height: 100px;
  padding: 0px 0px !important;
  text-indent: 2vw;
  /* margin: 0 -15px -15px; */
  overflow-y: auto;
 
  /* border-width: thin; */
  /* border-style: ridge; */
  /* width: 100%;
   */
}

.a11yEditor-focused{
  border-width: 2px;
  border-color: #3f51b5;

  top: -5px;
  left: 0;
  right: 0;
  bottom: 0;
  margin: 0 1px 0 0;
  padding: 0;
  /* position: absolute; */
  transition: padding-left 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms,border-color 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms,border-width 200ms cubic-bezier(0.0, 0, 0.2, 1) 0ms;
  border-style: solid;
  border-radius: 4px;
}

.a11yEditor-labelFocused,
.a11yEditor-labelFocused span
{
  color: #3f51b5;
}

.a11yEditor-error{
  border-color: #f44336;
}

.a11yEditor-labelError,
.a11yEditor-labelError span
{
  color: #f44336;
}

.a11yEditor-editor blockquote {
  display: block;
  border-width: 2px 0;
  border-style: solid;
  border-color: #`;
  padding: 1.5em 0 0.5em;
  margin: 0 6em;
  position: relative;
}
.a11yEditor-editor blockquote:before {
  /* content: '\201C'; */
  position: absolute;
  top: 0em;
  left: 50%;
  transform: translate(-50%, -50%);
  background: #fff;
  width: 3rem;
  height: 2rem;
  font: 6em/1.08em 'PT Sans', sans-serif;
  color: #666;
  text-align: center;
}
/* .a11yEditor-editor blockquote:after {
   content: "\2013 \2003" attr(cite); 
  display: block;
  text-align: right;
  font-size: 0.875em;
  color: #e74c3c;
} */

.hide{
  display: none!important;
}

.a11yEditor-editor ul,
.a11yEditor-editor ol, 
.public-DraftStyleDefault-ol
{
  padding-inline-start:40px;
}

.a11yEditor-error-heading{
  border-width: 1px;
  border-style: dotted;
  border-radius: 4px;
  border-color: #f44336;

}

Part I
Storytelling requires students to upload images and upload voice over images.
Students have choice to share it with classmates or just with the teacher(facilitator)

Here is an example please see https://vimeo.com/91494225
Some of the other examples are here from our students:
http://www.digitalstoryhub.org/filter/int/ERASMUS-IP-Project-Snapshot-Digital-Storytelling-Workshop
We are looking for a solution to make story production easier in the platform for students.

Expected Behavior

Initial accessibility status should be 0/6

Current Behavior

Initial accessibility status should be 1/6

Steps to Reproduce

1. Create a video content
2. Select to configure accessibility

Possible Solution

Apparently, it's calculating accessibility status as valid for long description

Related issues

https://material-ui.com/pt/guides/responsive-ui/

https://developers.google.com/web/fundamentals/design-and-ux/responsive/patterns?hl=pt-BR

Accessibility Images Configurations

PDF Documents

• Tip: If you added alternative text for an image in MS Word or Open Office, then that text will carry over when you save the document as a PDF. You can fix your images in Acrobat by clicking “Set Alternate Text” under “Accessibility” tools. More details: https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html

MS Word Documents

• Tip: You can add alt text to images right-clicking the object and select Edit Alt Text or Select the object and Select Format > Alt Text. More details: https://support.microsoft.com/en-us/office/video-improve-accessibility-with-alt-text-9c57ee44-bb48-40e3-aad4-7647fc1dba51

Open Office Documents

• Tip: To add alternative text to an image, right-click the image and select Picture (or double click the picture, or select Format > Picture from the menu bar). Then select the Options tab and enter the description in the box labeled Alternative (Text only). More details: https://www.openoffice.org/ui/accessibility/

Currently

• Tip: small help near a concept or form field. It’s preceded by and info icon. Default color is grey. When linked to a form field, it changes to red when an error in the input is detected. Also, it could change for green to denote an accessibility good configuration.

• Help: a visual example of the concept or the input expected in the form field. It’s a text button with a label “more details” preceded by a help icon.

• Guided help: yes/no question to help user decide between options. It’s a text button with a label “help me decide” preceded by a live help icon.

Modifications

Live-demo
(source)

• add ErrorMessage
  Instead of update the tip message when a error occur, show the error message in a different container, above of the tip.
  • role="alert"
  • use an icon to represent the error message
  • use a color to represent the error. The same that is used in the input field.
• Do not change the Tip color on error. Keep it gray
• The input will have aria-describedby=[id of tip container]
• Every component should have an unique ID

Informe at the beginning of every form that * is for required fields or [BEST] replace * for (required)

On error:

• Include a feedback text for the entire form
• Identified the field with error (sensory & text) #131
• Describe the error and how to fix #133

Suggested implementation

/*Using ARIA Live Regions or role=alert to Identify Errors*/
//OR <span id="errors" role="alert" aria-atomic="true"> /*ONE LINE PER ERROR*/</span> 
//OR <span tabindex="-1" id="errText" aria-live="assertive">/*ONE line summarising all errors*/</span>
<form name="signup" id="signup" method="post" action="#">
     <label for="first">Name (required)</label><br>
     <input type="text" name="first" id="first" aria-describedby="error_first">
<span id="error_first" role="alert" aria-atomic="true">/*ONE LINE PER ERROR*/</span> 
     <label for="email">Email (required)</label><br>
     <input type="email" name="email" id="email" aria-invalid="true" aria-describedby="error_email">
<span id="error_email" role="alert" aria-atomic="true"> /*ONE LINE PER ERROR*/</span> 
     <input type="submit" name="button" id="button" value="Submit">
</form>

If user select to change the audio content file, but closes the form, the system breaks.

Expected Behavior

Close modal and stays on authoring tool.

Current Behavior

Redirects to a blank page.

Steps to Reproduce

1. Create an audio content
2. Select the option to edit it
3. Select the option to upload a new audio file
4. Close the form

Possible Solution

Possible Implementation

Console log

ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9 TypeError: Cannot read property 'link' of undefined
    at f.render (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:131)
    at vs (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at fs (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Nc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Yc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Xc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Pc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
    at t.unstable_runWithPriority (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at uo (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
Bs @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Us.r.callback @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Vo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Io @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Zc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
t.unstable_runWithPriority @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
uo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Jc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Pc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
(anonymous) @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
t.unstable_runWithPriority @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
uo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
vo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
fo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
le @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
jr @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:131 Uncaught TypeError: Cannot read property 'link' of undefined
    at f.render (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:131)
    at vs (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at fs (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Nc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Yc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Xc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at Pc (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
    at t.unstable_runWithPriority (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
    at uo (ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9)
render @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:131
vs @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
fs @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Nc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Yc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Xc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
Pc @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
(anonymous) @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
t.unstable_runWithPriority @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
uo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
vo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
fo @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
le @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9
jr @ ca442eaa0b4b125aafcdc2c900fb1383f1cac271.js?meteor_js_resource=true:9

File dialog initiate with a filter for audio files (mp3, wav and ogg?) but user can upload any kind of file: other types of audio extensions and even not audio files.

Expected Behavior

User can't upload a file outside the restriction type.

Current Behavior

User can select any kind of file, even no audio types (e.g.: pdf)

Steps to Reproduce

1. Opens file dialog ("Click here to upload a audio file")
2. Switch the filter "Audio file" for "All files"
3. Select a *.pdf file
4. System will upload it with no error and render a player as it was uploaded an audio content.

Possible Solution

Need to perform validation on client-side and server (MIME-type). The accept attribute only helps filtering the files, it not restrict.

• Rearrange vertically
• No text with image as background
  • Remove background images.
  • If want to style the page with image, align it side by side with text, not in background

NOTE: Some accessibility problems will be fixed with this design

1. Dialog
   1. Alertdialog
   2. FullWidth dialog for widgtes
   3. How to implement with accessibility
2. Alert
   1. How to implement with accessibility

Dialog

A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert.

Do:

• Outlined buttons
• Close button (except in situations that dialog may not be closed)
• Left align

Example of current dialogs in SELI platform
No consistency!

Alertdialog

An alertdialog divert users' attention to a brief, important message and can receive a response from user. Ensuring that, while the alertdialog is shown, keyboard and mouse interactions only operate within the dialog.

Fullwidth dialog

How to implement with accessibility

https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal

https://www.w3.org/TR/wai-aria-practices-1.1/#alertdialog

role= dialog | alertdialog
aria-labelledby=Title
aria-describedby=Content //content that describes the primary purpose or message of the dialog.Enables screen readers to announce the description along with the dialog title and initially focused element when the dialog opens.
aria-modal=true //Tells assistive technologies that the windows underneath the current dialog are not available for interaction (inert). Replaces aria-hidden
aria-expanded="true" // To make the content easier to read when displayed on small screens, the dialog fills 100% of the screen.

Alert

An alert is an element that displays a brief, important message in a way that attracts the user's attention without interrupting the user's task. Since alerts are not required to receive focus, content authors SHOULD NOT require users to close an alert.

How to implement with accessibility

https://www.w3.org/TR/wai-aria-practices-1.1/#alert

<Snackbar
  ContentProps={{
    	'aria-describedby': 'snackbar-fab-message-id',
    	'role': 'alertdialog|alert',
'aria-live': 'assertive',
'aria-atomi': 'false',
  }}
  message={<span id="snackbar-fab-message-id">Archived</span>}
/>

If a time limit is set by the content, the user must be able to turn off, adjust, or extend the time limit.

Expected Behavior

The user with accessibility needs must receive the same updates that a common user receives. For exemple, by making the screen reader informs to the student that the time is running out.

Current Behavior

There is no alert about quiz time.

Steps to Reproduce

As student

1. Navigate to a couse
2. Start a Quiz Activity
   1. No option to turn off, adjust, or extend the time limit.

Environment

Browser: all

Possible Solution

Give teacher the option to

• enable extra time for students with disabilities and/or
• disable time (if extra time or no time is chosen, content is accessible)

Give student the option to

• request the extra time and/or
• remove time

User story

As a TEACHER I want to SETUP QUIZ WITH ALTERNATIVES TIMES CONSTRAINT

ACCEPTANCE CRITERIA

• Scenario: Quiz without time constraint
  GIVEN that I'm configuring a quiz
  WHEN I set time to 0
  THEN, quiz is created without time constraint

• Scenario: Quiz with time constraint and extended time
  GIVEN I'm configuring a quiz
  WHEN I set time to greater than 0
  AND select a extended time greater then 0
  THEN , quiz is created with time constraint and extended time for student with special needs

• Scenario: No-time option for a Quiz with time constraint
  GIVEN I'm configuring a quiz
  WHEN I set time to greater than 0
  AND select no-time option
  THEN , quiz is created with time constraint and no-time option for student with special needs

• Scenario: Quiz with time constraint and extended time and no-time options
  GIVEN I'm configuring a quiz
  WHEN I set time to greater than 0
  AND select a extended time greater then 0
  AND select no-time option
  THEN , quiz is created with time constraint and extended time and no-time options for student with special needs

Related Design Notes

#103
#105

Related features

#39

[Optional] Developer team add your technical tasks here

• [ ]
• [ ]

[Optional] Tester team, add your test procedures here

Expected Behavior

After video content is created, user must have the option to configure the accessibility resources immediately.

Current Behavior

Only the option to configure the accessibility later is enabled for user.

Steps to Reproduce

1. Upload a video file
2. Give a title and optionally a external link and description
3. Click the button "create content"

Possible Solution

Possible Implementation

Issue reference

#2

1.2.3

Dev Tasks

AUTHORING TOOL

• Give teacher the option to upload an audio description as a .vtt file or a alternative audio track (in Audio Description tab)
• [media alternative] Give teacher the option to inform a transcription (in Text Alternative tab)
  This approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. An alternative for time-based media provides a running description of all that is going on in the synchronized media content.

STUDENT MODULE

• Render video with the above resources using techniques in #159

Sufficient techniques

G78: Providing a second, user-selectable, audio track that includes audio descriptions

The objective of this technique is to provide an audio (spoken) version of information that is provided visually so that it is possible for people who cannot see to be able to understand audio-visual material.

Example

1. A travelogue of the northeast has additional audio description added during the gaps in the dialogue to let listeners who are blind know what the person is talking about at any point in time.
2. A video shows a woodpecker carving a nest in a tree. A button within the content allows users to turn the audio description track on or off.
3. A lecture has audio description added whenever the instructor says things like "and this is the one that is most important." The audio descriptions lets listeners who can not see the video know what "this" is.
4. A movie file has two audio tracks, one of which includes audio description. Users can choose either one when listening to the movie by selecting the appropriate track in their media player.

Test Procedure

1. Check that the ability exists to turn on the audio track that includes audio descriptions. For example, by using a control within the content itself or by selecting a control or preference in the media player or operating system.
2. Listen to the synchronized media
3. Check to see if gaps in dialogue are used to convey important information regarding visual content

Expected Results

Checks # 1 and # 3 are true.

G173: Providing a version of a movie with audio descriptions Using any player that supports audio and video

The objective of this technique is to provide a second version of video content that provides audio desciptions so that it is possible for people who cannot see to be able to understand audio-visual material.

Example

1. Two versions of a video of an opera are available. The first version includes only the music. The second version includes both the music and voice describing the actions of the performers on stage.
2. A video of juggler performing in front of group of children includes a version with audio description. The narrator of the audio description describes the number and type of items the juggler is juggling as well as the reactions the children have during the performance.

Test Procedure

1. Open the version of the media that includes audio description.
2. Listen to the movie.
3. Check to see if gaps in dialogue are used to convey important information regarding visual content.
4. If the alternate version(s) are on a separate page, check for the availability of link(s) to allow the user to get to the other versions.

Expected Results

Checks # 3 and # 4 are true.

G8: Providing a movie with extended audio descriptions Using any player that supports audio and video

The objective of this technique is to provide a second version of video content that provides extended audio descriptions. One of the difficult things about creating traditional audio descriptions is that the narrator sometimes has to provide a lot of information during very short pauses in dialogue. Extended audio description temporarily pauses the audio and video to allow critical information to be delivered when pauses in dialogue are insufficient for adequate description.

Example

1. An alternate version of an online video of a family escaping from a burning building: there is a continuous dialogue between the husband and wife about where the children are. Meanwhile, in the background, a wall caves in. This is important information in the story because it will block their exit from that part of the building. The video track halts (same frame is repeated) while a narrator gives the details about the wall falling and the video continues.
2. A training film has narrative that runs almost continuously throughout. An alternate version is available for people who have difficulty viewing the video portion. The alternate version freezes the video and provides audio description of key information.

Test Procedure

1. Open the version of the movie that includes extended audio descriptions.
2. Check that the video halts for extended audio description when there is not enough space to include necessary narration between the natural dialogue.
3. Check that the necessary information is in the audio description.
4. If the alternate version(s) are on a separate page, check for the availability of link(s) to allow the user to get to the other versions.

Expected Results

Checks # 2, # 3 and # 4 are true.

G203: Using a static text alternative to describe a talking head video

The purpose of this technique is to provide an alternative to audio description (...) This particularly applies to "talking head" videos where a person is talking in front of an unchanging background, such as a press conference, company president talk, or government announcement, etc. In this case there are no "important visual details" which would warrant audio description.

Example

1. A video of a CEO speaking to shareholders
   A CEO is speaking to shareholders from his office. The video has a title page at the beginning of the video giving the date. When the speaker begins, there is a strip of text at the bottom of the video saying "John Doe, President of XYZ Cooperation". At the end of the video are title credits that say "produced by the Honest TV Productions Ltd."
   As an alternative, there is a paragraph below the video which is associated with the video file using aria-describedby which says: "July 22, 2011, John Doe, President of XYZ cooperation, speaking from his office. Video produced by the Honest TV Productions Ltd."

Test Procedure

1. Check that there is no important time-based information in the video track
2. Check that the programmatically associated description of the media contains any context of the content that is not contained in the audio track (e.g. speaker identification, credits, context)

Expected Results

All checks are true.

Advisory Techniques

Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content.
Advisory techniques are not designated as sufficient techniques for various reasons such as:

• they may not be sufficient to meet the full requirements of the success criteria;
• they may be based on technology that is not yet stable;
• they may not be accessibility supported in many cases (for example, assistive technologies do not work with them yet);
• they may not be testable;
• in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;
• they may not address the success criterion itself, and instead provide related accessibility benefits.
  Authors are encouraged to apply all of the techniques where appropriate to best address the widest range of users' needs.

H96: Using the track element to provide audio descriptions

use the HTML5 track element to specify a descriptions timed text track for a video element. Audio description timed text tracks contain textual descriptions of the video component of the media resource, intended for audio synthesis when the visual component is obscured, unavailable, or not usable.

❗ IMPLEMENTATION ALERT As of February 2019 when this Advisory technique was last reviewed by the Working Group, there is no native support in user agents for this technique. However, support is available via JavaScript polyfills.

Example

<video poster="myvideo.png" controls>
  <source src="myvideo.mp4" srclang="en" type="video/mp4">
  <source src="myvideo.webm" srclang="fr" type="video/webm">
  <track src="myvideo_en.vtt" kind="descriptions" srclang="en" label="English">
  <track src="myvideo_fr.vtt" kind="descriptions" srclang="fr" label="French">
</video>   

Test Procedure

For each video element used to play a video:

1. Check that the video contains a track element of kind descriptions in the language of the video.

Expected Results

Check # 1 is true.

Resources

For G78

• HTML5 multi-track audio or video
• Codepen.io Example
• Howler.js

Referenced Requirements

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria

GLOSSARY

• SELI's content: all contents not created by users (e.g. seli "about" section text)

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

1.2.6

Sign language interpretation is provided for all prerecorded audio content in synchronized media.

Tasks

List the tasks required to accomplish the requirement (not exhaustive)

• SYSTEM MUST include SELI's videos contents with sign language for all videos that student may consume.

• IF TEACHER uploads a video content, i.e. video-only checkbox not checked

  • SYSTEM MUST provide a checkbox to TEACHER marks if the video has sign-language embedded. G54

• IF TEACHER uploads a video content without embedded sign-language, i.e. embedded sign-language checkbox not checked

  • SYSTEM MUST provide an option to TEACHER uploads a video of the sign language interpreter. G81

• SYSTEM MUST render teacher's video content with it sign-language, if teacher configure one.

Resources

For G81

• HTML5 multi-track audio or video
• Able Player 2.01

Able Player is a fully accessible cross-browser HTML5 media player.

Intent

The intent of this Success Criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of synchronized media presentations.

Examples

1. Example 1. A corporation is making an important announcement to all of its employees. The meeting will be held in the main headquarters and streamed to the Web. A sign language interpreter is provided at the meeting location. The live video includes a full view of the sign language interpreter as well as the person presenting.
2. Example 2. The same announcement described in example 1 is also Webcast to remote employees. Since there is only one display available for this, the sign language interpreter is shown in the corner of the display.
3. Example 3. A university is providing an on-line version of a particular lecture by creating a synchronized media presentation of the professor delivering the lecture. The presentation includes video of the professor speaking and demonstrating a science experiment. A sign language interpretation of the lecture is created and presented on the Web with the synchronized media version.

Sufficient Techniques

Sufficient techniques are reliable ways to meet the success criteria.

• From an author's perspective: If you use the sufficient techniques for a given criterion correctly and it is accessibility-supported for your users, you can be confident that you met the success criterion.
• From an evaluator's perspective: If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion. (The converse is not true; if content does not implement these sufficient techniques, it does not necessarily fail the success criteria, as explained in Testing Techniques below.)
  There may be other ways to meet success criteria besides the sufficient techniques in W3C's Techniques for WCAG document, as Other Techniques below. (See also Techniques are Informative above.)

• G54
• G81

# G54: Including a sign language interpreter in the video stream

One universally compatible way of doing this is to simply embed a video of the sign language interpreter in the video stream. This has the disadvantage of providing a lower resolution image that cannot be easily enlarged without enlarging the entire image.

NOTE
If the video stream is too small, the sign language interpreter will be indiscernible. When creating a video stream that includes a video of a sign language interpreter, make sure there is a mechanism to play the video stream full screen in the accessibility-supported content technology. Otherwise, be sure the interpreter portion of the video is adjustable to the size it would be had the entire video stream been full screen.

Since sign language is not usually a signed version of the printed language, the author has to decide which sign language to include. Usually the sign language of the primary audience would be used. If intended for multiple audiences, multiple sign languages may be used. Refer to advisory techniques for multiple sign languages.

Example

1. A television station provides a sign language interpreter in the corner of or beside its on-line news video.

Test Procedure

1. Have someone watch the program who can hear and is familiar with the sign language being used.
2. Check to see if there is a sign language interpreter on screen.
3. Check to see that dialogue and important sounds are being conveyed by the interpreter visible on screen.

Expected Results

Check # 2 and # 3 are true

G81: Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player

This technique accomplishes this by providing the sign language interpretation as a separate video stream that is synchronized with the original video stream. Depending on the player, this secondary video stream can be overlaid on top of the original video or displayed in a separate window. It may also be possible to enlarge the sign language interpreter separately from the original video to make it easier to read the hand, body and facial movements of the signer.

Example
A university provides a synchronized sign language interpreter video stream that can be displayed, at the viewer's option, along with any of their education programs.

Test Procedure

1. Enable the display of the sign-language window in the player.
2. Have someone watch the program who can hear and is familiar with the sign language being used.
3. Check to see if there is a sign language interpreter on screen or in a separate window.
4. Check to see that dialogue and important sounds are being conveyed by the interpreter and are synchronized with the audio.

Expected Results

Check #3 and #4 are true

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria

GLOSSARY

• SELI's content: all contents not created by users (e.g. seli "about" section text)

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

• One column
• Left align
• Submit button on bottom

Expected Behavior

Should have the "Others" tab

Current Behavior

Possible Implementation

See previous code
Line 140 and Line 306

Related issues

GUIDELINE

Principle

PERCEIVABLE: Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses) Provide text alternatives for non-text content. Provide captions and other alternatives for multimedia. Create content that can be presented in different ways, including by assistive technologies, without losing meaning. Make it easier for users to see and hear content.

Level of Conformance

A (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided

Referenced Requirements

Reference requirements that should be meet together
#9

General description

An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.

Intent

Alternatives for time-based media that are text based make information accessible because text can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user. In the future, text could also be translated into symbols, sign language or simpler forms of the language (future).

Examples

1. An audio recording of a speech
   The link to an audio clip says, "Chairman's speech to the assembly." A link to a text transcript is provided immediately after the link to the audio clip.
2. An audio recording of a press conference
   A Web page includes a link to an audio recording of a press conference that identifies the audio recording. The page also links to a text transcript of the press conference. The transcript includes a verbatim record of everything the speakers say. It identifies who is speaking as well as noting other significant sounds that are part of the recording, such as applause, laughter, questions from the audience, and so on.

Techniques

• G158: Providing an alternative for time-based media for audio-only content

This technique involves creating a document that tells the same story and presents the same information as the prerecorded audio-only content. In this technique, the document serves as long description for the content and includes all of the important dialogue and as well as descriptions of background sounds etc. that are part of the story.

Test

Procedure

1. View the audio-only content while referring to the alternative for time-based media.
2. Check that the dialogue in the transcript matches the dialogue and information presented in the audio-only presentation.
3. If the audio includes multiple voices, check that the transcript identifies who is speaking for all dialogue.
4. Check that at least one of the following is true:

• The transcript itself can be programmatically determined from the text alternative for the audio-only content
• The transcript is referred to from the programmatically determined text alternative for the audio-only content

5. If the alternate version(s) are on a separate page, check for the availability of link(s) to allow the user to get to the other versions.

Expected Results

All of the above checks are true.

SELI CONTEXT

How to implement this requirement on SELI Platform?

<div id="id_video_box">
   <h3>Audio title</h3>
   <p id="id_short_desc"><!-- SHORT DESCRIPTION --></p>
   <h3><button aria-expanded="false" aria-controls="id_req_acc">Available accessibility resources</button></h3>
   <ul id="id_req_acc">
  	<li>Transcriptions</li>
   </ul>
   <audio id=audio autoplay="false" autoplay="controls" aria-describedby="id_long_desc" aria-labelby="id_short_desc">
       <source src="audio.mp3" type='audio/mpeg'/>
   </audio>
</div>
<button aria-expanded="false" aria-controls="id_long_desc">Audio Transcription</button>
<div><p  id="id_long_desc"><!-- TRANSCRIPTIONS --></p></div>

Tasks

List the tasks required to accomplish the requirement (not exhaustive)

• DEVELOPER MUST include audio-only contents with it text alternative

All contents not created by users (e.g. SELI "about" section text, buttons, fields) that STUDENT could consume

• When TEACHER upload an audio-only content SYSTEM MUST provide a field to TEACHER write/paste a text transcription

• SYSTEM MUST render teacher's content with it respective text alternative, if teacher configured one

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria
• aria-describedby for longer text alternative
• Transcript Examples

GLOSSARY

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

1.2.8

Referenced Requirements

• For contents that are prerecorded synchronized media, to meet this requirement, SHOULD implement #11 with G69 technique

• For contents that are video-only, to meet this requirement, SHOULD implement #9 with G159 technique

General description

An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media.

ℹ️ For 1.2.3(#11), 1.2.5(#12) , and 1.2.7(#13), if all of the information in the video track is already provided in the audio track, no audio description is necessary.

Intent

This approach involves providing all of the information in the synchronized media (both visual and auditory) in text form. An alternative for time-based media provides a running description of all that is going on in the synchronized media content. The alternative for time-based media reads something like a book. Unlike audio description, the description of the video portion is not constrained to just the pauses in the existing dialogue. Full descriptions are provided of all visual information, including visual context, actions and expressions of actors, and any other visual material. In addition, non-speech sounds (laughter, off-screen voices, etc.) are described, and transcripts of all dialogue are included. The sequence of descriptions and dialogue transcripts is the same as the sequence in the synchronized media itself. As a result, the alternative for time-based media can provide a much more complete representation of the synchronized media content than audio description alone.

Examples

A community center purchases a Training video for use by its clients and puts it on the center's intranet. The video involves explaining use of a new technology and has a person talking and showing things at the same time. The community center provides an alternative for time-based media that all clients, including those who can neither see the demonstrations nor hear the explanations in the synchronized media, can use to better understand what is being presented.

Sufficient Techniques

📔 References

• How to Meet WCAG (Quick Reference)
• Understanding Techniques for WCAG Success Criteria

GLOSSARY

• SELI's content: all contents not created by users (e.g. seli "about" section text)

⚠️ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119/8174.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Expected Behavior

When user mark that video hasn't sign language interpreter embedded, the system enabled the upload button

This was working properly before please have a look at change history of the code.
How it work before

1. Initial state: Not embedded, accessibility resource is invalid
   
2. Embedded , accessibility resource is valid
   

This was simplified version for prototype not covering the option to upload an additional video of the interpreter. To fully attend WCAG requirement, see requirements #15

Current Behavior

When user mark that video **has sign language interpreter **, the system enabled the upload button

Possible Solution

Please refer to task section of requirement #15