tabindex="-1" had dynamically been added to the target div. Here’s a quick video cap of the interaction:
[riley.macisaac] Curious if there is anything in the works for automated testing (like Axe for example) that flags issues in which there are focusable items inside of an element that is positioned off screen, but still accessible via keyboard/taborder.
Example: Mega menu has opacity 0, so is visually hidden but not hidden from screen readers or keyboard access.
Would be cool if that was flagged.
[tink] If membership is required, that text needs to be visible to everyone.
To indicate a field is required, you can use an asterisk (*) as part of the visible text label. You can also use the aria-required attribute (set to true) to reenforce the required state of the field to screen reader users.
Don't forget that the label for each field needs to be visible, and properly associated with the field in the code.
This is a good accessible forms tutorial:
https://webaim.org/techniques/forms/
Lastly, get rid of the modal if you can. No-one's going to like it much, and making modals accessible is painful.
[drewwarrentiy] Can anyone explain to me
ARIA hidden element must not contain focusable elements
In terms of technical implementation of the solution, I think I understand. I could crawl through the DOM, find all children that are interactive and set the disabled property or some of the other suggestions from https://dequeuniversity.com/rules/axe/3.3/aria-hidden-focus?application=AxeChrome
But I don't quite understand why children of an element that is aria-hidden="true" would need to ALSO be set to disabled since they shouldn't be able to be reached by Assistive Technologies anyways. The "Why this is important" paragraph in that link describes that it is important but I'm not grasping the "why".
aria-hidden="true" doesn’t remove a focusable element from the tab order
aria-hidden=true wrapper, they’d hear no announcement for the focus stop
clip: rect(1px, 1px, 1px, 1px) while others use 0s, some use clip-path: inset(50%) while others use 100%. Is there any good source that breaks down the what and the why, particularly compared to others? I even saw one reference to setting top: auto because some browsers didn’t respect the left value without a top value.
I’m hesitant to even say it’s good idea to have a feature app that helps make a site “more accessible”. My gut is no, but would like some weight to my response to the team member and/or hear other’s thoughts about this (good or not).