Accessibility Issues in Rise

Thank you for your willingness to receive feedback. I really appreciate it and have been working with my company's accessibility team on projects. They pointed out a few issues that upon investigation, I was unable to change within Rise. If these are known topics for future development or if they could be added to the list, would you be willing to share? Thanks again for your support.

1. It is best practice (and expected behavior) that LINKS navigate users to a place on the page or to another page. BUTTONS should be used to perform an action. Screen reader users would not expect to come to a “button” that would navigate them to a section of a page.
2. Hamburger menu toggle button needs to provide context to user when it is in focus: is it open, or is it closed?
   1. When the user takes action on the button, the toggle menu should communicate that current state again (open/closed).
   2. A keyboard only user also needs to be able to move between the open toggle menu content area and main content area. I was not able to do that on the Mac. I don’t recall if Emily or Howard were able to via the PC.
3. Quotation marks for null alt tag: Articulate is literally encoding quote quote in the ALT attribute that is being read by the screen reader as actual content. This will confuse people hearing “quote quote”. When coded correctly, a null (or blank) ALT attribute should not read anything and skip the image. I would recommend to Articulate that they provide a “This image is decorative only (provides no meaning to the user)” checkbox simplify the process for the Articulate user and provide a better experience for the screen reader user.
4. Figure: FIGURE is an HTML element that is a “self-contained” single unit of content. It is often used to wrap illustrations, diagrams and similar content. It can optionally have a caption tag added to provide more context about the content. The experience we had was the screen reader (JAWS) would read “figure” along with other text, but the word “figure” meant nothing to us within the content. The information that was provided while it read “figure” didn’t make sense. I think it makes sense to have this as a FIGURE element, but I would recommend to Articulate that they provide a FIGCAPTION tag along with the FIGURE to properly describe the FIGURE tag content.
5. The flip cards are related content that need to have programmatic text associated with them to convey the relationship to the user. They should have text that properly describes the content or instructs the user what to do with them much like a legend does for a fieldset of related checkboxes.
6. Same general detail as #5 above that fieldsets should have a legend to describe the related controls.
   1. All inputs (checkboxes and radio buttons) must have a programmatic label appropriately associated with them. When a control in a fieldset gets focus, the fieldset legend (the fieldset label) should be read and each option should be read as the user navigates the options. Each control should have a programmatic state that is conveyed to the assistive technology (e.g.: checkbox is checked or unselected?). Currently, the checkbox options are not useable by a screen reader user.
   2. Feedback was skipped: There is no programmatic awareness of the feedback provided visually. A screen reader user would need to have the same information provided on submission of the form. Currently, they receive no feedback on submission.
   3. ALSO to note, the button following the success/failure message is a “retake quiz” button that always exists. This button should NOT be provided until the user has taken the quiz and has been provided the proper context that they have passed or failed the quiz. Without the proper context, a screen reader user may think: 1. They are missing something or doing something wrong, or 2. That the “system/solution” is not working. Whatever the case, the user would likely not complete or move forward.
   4. Radio buttons don’t meet contrast ratio: The outline that creates the shape of both radio buttons and checkboxes. The color that I sampled that creates the both control shapes is #D6D7D7. That light gray color against a white background only hits a 1.44:1 contrast ratio. To meet accessibility requirements, the control outlines must have at least a 3:1 contrast ratio to be perceivable.
   5. Submit button disabled: This is not a requirement, but best practice would be to always have the button enabled allowing the user submit the form. This ensures the user can always find what is not fulfilled in order to continue a workflow. Should the button be disabled and the fields be required, it could lead to an issue where the user would unable to continue.
   6. Only able to select first option: Not all checkbox or radio button options are accessible via a screen reader user
   7. Consistency in operation of radio buttons: users should be able to select or unselect similar controls in a consistent fashion.
7. Heading Levels: Heading levels should be set by the hierarchy of the page, not artificially set by a component dropped in to a page. Headings should be nested much like an outline is starting with only one H1 (heading level 1 – the page title), then nesting other content accordingly.
8. Section headers do not meet proper contrast ratios when they have keyboard focus. Blue color (sampled #6BACEB) against the light gray color (sampled #F0F0F0) do not meet the proper contrast ratios (scores a 2.11:1 contrast ratio). The font size of section header text is 14px which would require the text to meet at least 4.5:1 contrast ratio to pass accessibility requirements.
   1. Section headers are in an ANCHOR tag, but do not contain an HREF attribute which makes them not fully keyboard accessible in all browsers. All ANCHOR tags must contain an HREF attribute to be keyboard accessible.
9. When things change on the page (e.g. submit form and provide success message, same concept as 6.2), the updated content on the page or change of context must be available programmatically to allow assistive technologies to communicate the change to the end user.
10. Matching drag/drop cards need to have a programmatic label / instructions to properly describe the group of controls or what to do with them.
    1. The drag and drop functionality is not available to screen reader users. The keyboard alternative does not work with a screen reader turned on.
11. Lang attributes does not work.