My colleagues and I have identified a number of accessibility issues with v.2 of Adapt. Our testing is based on the Presentation, Question, and Assessment components in the online Demo.

We regularly do evaluations for our university, which is interested in potentially adopting Adapt.

We looked at general, keyboard, and screen reader accessibility in the desktop view. Mobile view accessibility has not been examined.

General usage feedback:

• Presentation: Video player should have ability for synchronized closed captioning and, ideally, the transcript region should be able to be synced with playback. Captions are essential to accessibility for deaf and hard of hearing users and can be beneficial to users in many circumstances -- noisy environment, enforced quiet, non-native language user, language acquisition, various cognitive disabilities, etc.

Keyboard usage feedback:

• When tabbing through (with accessibility feature enabled) all elements receive visual focus, including bold or italic styled text. The outlining is helpful, however, making styled elements within longer runs of text individually focusable is a distraction and could lead to confusion and extra, unnecessary tabbing. Also, in certain circumstances, with certain styling, the orange outlines outline each line of text separately. It is probably preferable to outline an entire block as a unit, rather than line by line, which could make for too much visual noise.
• Continue button in the Assessment is not keyboard accessible.

Screen Reader usage feedback: NVDA 15.5 + Firefox 44.0.2:

(Note: We use NVDA+Firefox because this combination tends to be most faithful to W3C recommendations in its audible rendering and object navigation.)

• The aria-label on the Turn accessibility on/off button overrides the button text. Better would be to get rid of the aria-label and just use the button text to convey function. In addition, use the aria-pressed state to indicate status as pressed (accessibility on) or not (accessibility off). (Note: if it is possible to not have such as toggle at all, that would be preferable. Why not just make the thing tabbable, always? Also, screen reader users can easily by-pass or simply miss such toggles. Best practice is to simply make the thing accessible and not have an "accessibility mode." Perhaps there are interactivity limitations we are not aware of that require activation of a "special" mode?)
• The aria-label "Close Drawer" for the right-hand "Resources" panel is insufficient. What is a "drawer?" Better would be "close resources panel." Similarly, the outline/progress indication panel also needs a more appropriately descriptive label for its close button: "close progress outline panel," or similar.
• The button for the progress/outline panel simply announces the progress percentage. Instead it should should say something like: "course outline: 40% completed" or equivalent.
• The headings in the demonstrations skip levels -- from H1 to H4. Heading levels convey the logical hierarchy of the document. Do not skip levels and be sure nesting is appropriate to semantics.
• The alternative text for the image in the Narrative carousel is read at one blow. Instead, only the alterative for the currently focused graphic should be announced. Also, we recommend giving the screen reader user an indication of progress through the narrative. For example, buttons could be updated to announce position: "Next. Item 2 of 3," etc.
• The video players controls are only minimally accessible to a screen reader user. Such a user cannot determine or control progress and the state of the play/pause button does not change to indicate play state. In addition, like the expanding Accordion regions, the Transcript region button should announce state of expanded/collapsed.
• In the Question Components, the "pop up panel" has its close button at the end of the tab/browse order. This is fine, but typically pop open dialogs can be closed via the escape key. We recommend implementing that functionality (even it the model present in the Resources and Progress Outline panels is used -- where Escape press takes the user to the close button).
• The inline progress indications after each question component report incorrectly as "[name of question] completed incorrect," even when the item has been correctly answered.
• For text input (or other multiple choice, checkbox, or radio button groupings) the question should be either associated via aria-labelledby or (probably better) be a fieldset legend. This way the user will know the question when he attempts to input an answer. If going the route of using aria-labelledby, our recommendation would be to make the associations function identically to how a fieldset grouping behaves -- question is read upon entering the grouping from either the "top" or the "botton" (first or last item in the grouping).
• Related, note that aria-labelledby can be used for the text box entries. Do not rely on placeholder text as an accessible label, since as soon as the user inputs a response (or hits backspace) the field's placeholder "prompt" is no longer read when entering the field. (aria-labelledby overrides all other labelling. So if you need to associate more than one element as a label, you must have all IDs listed as the value: aria-labelledby="id-of-first-label id-of-second-label" etc.
• The slider control buttons should probably have more context: "Slider button 4 of 10", for example, and, as above, the question should be announced when entering the slider button grouping.
•  As noted above in the keyboard testing, the "Continue" button in the Assessments was unreachable.