Hi, does the native vanilla build of Adapt 5 fully support WCAG 2.0?
Adapt 5 WCAG
Re: Adapt 5 WCAG
We aim for 2.1 but, and it's a big but, Adapt is JUST a framework, the content you put into the framework, all of the images, text and videos and styling, will determine whether your course passes or fails for people in the real world.
There are some parts of the Adapt framework that accessibility testing agencies will take issue with, for example, not using h tags or using aria-label instead of alt on images. We use the aria rather than the html standard in some places.
Headings: wiki, adapt issue , aria-level
Image alt: adapt issue
Re: Adapt 5 WCAG
Unfortunately we are seeing a LOT more fails with the native Adapt framework extensions and components with our accessibility testers.
For example, in the Drawer alone:
1. Tab focus should not move to non interactive elements. Provide tab indexing= 0 do that focus does not move to the non interactive elements.
https://www.screencast.com/t/7TXIfuJo1
2. Button role is unnecessarily provided for plain text. Button role is unnecessarily provided for text 'Click here to view..., view resources for this...'.Button role should not be provided for plain text. Button role should only be given to text 'Audio' and 'Resources'. If button role will be provided for plain text then it will confuse the screen reader users. Remove button role from plain text.
https://www.screencast.com/t/5Bo9CeFyL53
3. Expanded/ collapsed state of hamburger menu (Drawer) are not announced. Provide expanded/ collapsed for hamburger menu.
https://www.screencast.com/t/ar1EXj15R
4. Screen reader does not announce the selected state of currently active button. Screen reader should announce the selected state of currently active button. Without the selected state, screen reader users would not be able to identify the currently active link. Visit this link for the code:
https://www.w3.org/WAI/PF/aria/states_and_properties#aria-selected
https://www.screencast.com/t/1b2xs9Gu9
This is adapt 5.18.2.
Re: Adapt 5 WCAG
There's a couple of things I need you to understand before we correct the issues you've listed.
a) The tab cursor, moved with javascript .focus or tab or clicking is not the screen reader cursor. The screen reader cursor does not set focus on elements, it only reads the text provided (body text, aria-label or aria-labelledby). Setting focus on any element will move the screen reader cursor but moving the screen reader cursor will not change the focus.
b) When we describe FAILURE against the WCAG, there are very specific rules we can refer to and should reference.
1. Tab focus should not move to non interactive elements. Provide tab indexing= 0 do that focus does not move to the non interactive elements.
> What you're showing is the screen reader cursor, not the tab focus/cursor. The screen reader is reading an additional arialabel which describes the region for the user. Additionally, tabindex=0 is often used to allow the tab focus to move to non-interactive elements as the screen reader cursor follows the tab focus, this is standard practise, appears in WCAG examples and is not a fail by WCAG rules.
2. The button role exists on the parent element. The title and body span are children of the button. This is exactly as expected, you will need to inspect the DOM using a debugger to see how the HTML is arranged.
3. Expanded/collapsed is usually only relevant for non-modal user interface elements. Here, when the drawer is open the menu button is not accessible, a user would never hear the 'expanded' state as they cannot access the button whilst the drawer is open. Having said that, it's an interesting idea to add 'collapsed' to the menu button as it may provide indication to the user that the drawer is togglable. Could you raise an issue on the core? Drawer is part of the core at the moment https://github.com/adaptlearning/adapt-contrib-core/issues
4. Agree. Could you raise an issue on the resources plugin please? https://github.com/adaptlearning/adapt-contrib-resources/issues Please reference the spec as you've done above.
Re: Adapt 5 WCAG
Thanks for this, i've added the issues to the appropriate gits, and I have looped back with our accessibility tester about what you consider to not be issues. I agree with you, as well as another adapt developer I speak with, but I wanted to be sure. I think accessibility testers are just always trying to find things and get a bit overzealous.
Re: Adapt 5 WCAG
>
Unfortunately we are seeing a LOT more fails with the native Adapt framework extensions and components with our accessibility testers.
Could you provide a list of the failures please? I'm sure we can address them all fairly easily.
Re: Adapt 5 WCAG
Sorry for the delay here are some others:
1. Media Player:
Caption button is not accessible through tab/ arrow keys. When user hits enter on it then nothing happens.
https://www.screencast.com/t/mLvG21vtC
2. Hot Graphic
Tab focus is not constrained within Hot graphic button popup. Screen reader focus moves to background page.
If keyboard focus moves out of the popup, users would not realize that the content is not a part of the pop-up.
https://www.screencast.com/t/5RFK3FfgvnW
Construct a modal window/ popup which should be accessible.Focus should be trapped inside modal when it is open.
For details refer: https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html
Re: Adapt 5 WCAG
Sorry I missed another:
3. Tooltip is not provided for 'home, hambuger, ?, location' etc icons.
If tooltip will not be provided then user will not be able to identify the icons.
https://www.screencast.com/t/dgNlb7Gve6
1. Create a <div> element, give it a role="tooltip" and an id="IDREF". Then, give it a brief description of the action.
2. This element has to be accessible by focusing as well as hovering over. Both functionalities can be provided using CSS.
3. The tooltip has to be visually hidden using CSS.
4. Associate the tooltip with its button using aria-labelledby.
5. After applying this keyboard-accessible tooltip, consider removing the title attribute from the element.
Refer to:
https://inclusive-components.design/tooltips-toggletips/
https://a11yproject.com/posts/how-to-hide-content/