Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
JAWS announces all modal contents as "clickable" #986
We are using the Modal from Carbon Components in our product’s UI. We’ve been hit with an accessibility violation wherever we used the Modal component because the JAWS screenreader detects all the elements inside the modal, such as the header and any paragraphs, to be clickable and announces them as such. This should not happen as there are no click events bound to those elements.
We found that this is the case not just for modals in our UI but in the Carbon Components site (http://www.carbondesignsystem.com/components/modal/code) as well.
When JAWS reads non-interactive elements inside the modal such the header or a paragraph, it should just read the text inside those elements.
Currently, JAWS reads the text in the element and then says "clickable," which indicates that the element is interactive.
JAWS should just read the text and not announce "clickable" for non-interactive elements.
IBM Cloud Automation Manager
Need to fix accessibility issues and send it for another round of AVT before August 8th.
Steps to reproduce the issue
Please choose the appropriate label(s) from our existing label list to ensure that your issue is properly categorized. This will help us to better understand and address your issue.
JAWS (and NVDA) announce "clickable" when an element or one of its ancestors has a click event handler. (Seems to be worse in Firefox - not sure why).
For example, "clickable" is announced each time a JAWS user presses down arrow to read the p lines in the following div:
So since the "bx--modal" dialog container has a click handler, and since it's the parent of the "bx--modal-container", this is why the problem is happening.
Consider adding an overlay node that’s a sibling to the bx--modal-container and have that be the one that accepts click events to close the modal.
In case it's helpful, here's a (slightly old, but still mostly valid) video showing how to make an accessible modal dialog.
This video shows how to fix other accessibility problems that the Carbon modal dialogs have as well, such as screen reader users being able to accidentally move outside of the dialog just by typing their reading keys (for example, down arrow). Need to also make sure that shift+tab is trapped in the dialog (in the same way that typing tab is).
Hi @carmacleod thank you for your insights on this topic! Your insights suggesting a potential issue with JAWS with "event delegation" technique led me to https://webaim.org/discussion/mail_thread?thread=7693
Though I haven't had time to fully read the discussion thread, some posts seem to allude that having a proper role may fix the issue (though I'm not sure if it's true or not). Wondering if you have any insights on how to make an application with "event delegation" technique work well with JAWS? Thanks!
Hi @asudoh! Definitely try adding
Note that a properly marked up ARIA dialog needs more than just a role. Please see the section on dialog in the ARIA APG, and note that you need:
(Note that the aria-label[ledby] will be read before the aria-describedby).
If you like, I can test this for you in JAWS and NVDA after you mark it up. (I did not try VoiceOver to see if it says "clickable").