E-mail List Archives
Thread: Enquiry regarding NVDA Clickable announcement and WCAG
Number of posts in this thread: 6 (In chronological order)
From: Sumit Patel
Date: Tue, Jun 25 2024 8:32AM
Subject: Enquiry regarding NVDA Clickable announcement and WCAG
No previous message | Next message →
Hai all,
I am writing to enquire about the behavior of the NVDA screen reader when
encountering non-interactive elements. I understand that NVDA announces
"clickable" for interactive elements which is very helpful for users when
the element's role has not been assigned. However I have observed instances
where NVDA announces even non-interactive elements as clickable on various
websites. My concern is that this can create a confusing and frustrating
experience for screen reader users especially encountered frequently
throughout a page. I've heard that this might be due to the presence of
event handlers attached to these elements. Is the presence of event
handlers the only reason behind NVDA announcing clickable for
non-interactive elements ? Additionally does this behavior violate any
criteria within WCAG 2.2 guideline ?
I appreciate any clarification you can provide on this matter
Thanks in Advance,
Sumit.
From: Dean.Vasile@outlook.com
Date: Tue, Jun 25 2024 9:12AM
Subject: Re: Enquiry regarding NVDA Clickable announcement and WCAG
← Previous message | Next message →
Hi Sumit,
Thank you for reaching out with your question regarding NVDA's behavior when encountering non-interactive elements.
### NVDA Announcing "Clickable" Elements
You're correct that NVDA announces "clickable" for elements that it identifies as interactive. This feature is designed to help users navigate more effectively by highlighting elements that they can interact with, even if those elements don't have explicit roles or interactive semantics.
### Non-Interactive Elements Announced as "Clickable"
The issue you mentioned, where NVDA announces non-interactive elements as "clickable," can indeed stem from the presence of event handlers (such as `onclick`, `onhover`, etc.) attached to these elements. When NVDA detects these event handlers, it assumes that the element has some interactive functionality, leading to the "clickable" announcement. However, if these elements are not intended to be interactive, this can cause confusion.
### Other Potential Causes
Besides event handlers, other factors that might cause NVDA to announce an element as clickable include:
- Misuse of ARIA roles and properties.
- Elements styled to look like buttons or links using CSS.
- Scripts that dynamically change the interactivity of elements.
### WCAG 2.2 Compliance
Regarding WCAG (Web Content Accessibility Guidelines) 2.2, this behavior touches on several criteria related to ensuring that web content is perceivable, operable, and understandable:
- **WCAG 2.2 Criterion 1.3.1 - Info and Relationships**: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. If a non-interactive element is announced as "clickable," it might mislead users about the element's role.
- **WCAG 2.2 Criterion 3.2.4 - Consistent Identification**: Components with the same functionality within a set of web pages are identified consistently. Announcing non-interactive elements as "clickable" inconsistently can lead to confusion.
- **WCAG 2.2 Criterion 4.1.2 - Name, Role, Value**: For all user interface components, the name and role can be programmatically determined. Non-interactive elements should not have roles or properties that imply interactivity.
While this specific issue is not directly called out in WCAG, it falls under the umbrella of ensuring a coherent and predictable experience for users relying on assistive technologies.
### Recommendations
To avoid this issue and improve accessibility:
1. **Avoid Attaching Event Handlers to Non-Interactive Elements**: Only attach event handlers to elements that are meant to be interactive (e.g., buttons, links).
2. **Use Appropriate ARIA Roles**: Ensure that only interactive elements are given roles that suggest interactivity (e.g., `button`, `link`).
3. **Test with Screen Readers**: Regularly test your website with NVDA and other screen readers to identify and resolve such issues.
4. **Provide Clear Instructions and Feedback**: Make sure that any interactive elements are clearly marked and provide feedback to users about their interactiveness.
By following these practices, you can help ensure a more accessible and user-friendly experience for all users, including those using screen readers like NVDA.
I hope this clarifies your concerns. If you have any more questions or need further assistance, feel free to ask.
Thanks,
Dean Vasile
617-799-1162
> On Jun 25, 2024, at 10:32â¯AM, Sumit Patel < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hai all,
>
> I am writing to enquire about the behavior of the NVDA screen reader when
> encountering non-interactive elements. I understand that NVDA announces
> "clickable" for interactive elements which is very helpful for users when
> the element's role has not been assigned. However I have observed instances
> where NVDA announces even non-interactive elements as clickable on various
> websites. My concern is that this can create a confusing and frustrating
> experience for screen reader users especially encountered frequently
> throughout a page. I've heard that this might be due to the presence of
> event handlers attached to these elements. Is the presence of event
> handlers the only reason behind NVDA announcing clickable for
> non-interactive elements ? Additionally does this behavior violate any
> criteria within WCAG 2.2 guideline ?
>
> I appreciate any clarification you can provide on this matter
>
> Thanks in Advance,
> Sumit.
From: Sailesh Panchang
Date: Tue, Jun 25 2024 9:44AM
Subject: Re: Enquiry regarding NVDA Clickable announcement and WCAG
← Previous message | Next message →
Does this also not result from associating an event handler with a parent
element like a DIV (not ideal practice) and not specific individual
elements within that are really interactive?
I disagree with using SC 3.2.4 here ...the clickability announced is a
behavior wrongly being associated with the element. Not the element's
identity per se.
Thanks,
Sailesh Panchang | +1 (571) 344-1765
Technical Solutions Architect
Email: = EMAIL ADDRESS REMOVED =
Deque Systems Inc | - Accessibility for Good | www.deque.com
On Tue, Jun 25, 2024 at 11:12â¯AM = EMAIL ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:
> Hi Sumit,
>
> Thank you for reaching out with your question regarding NVDA's behavior
> when encountering non-interactive elements.
>
> ### NVDA Announcing "Clickable" Elements
>
> You're correct that NVDA announces "clickable" for elements that it
> identifies as interactive. This feature is designed to help users navigate
> more effectively by highlighting elements that they can interact with, even
> if those elements don't have explicit roles or interactive semantics.
>
> ### Non-Interactive Elements Announced as "Clickable"
>
> The issue you mentioned, where NVDA announces non-interactive elements as
> "clickable," can indeed stem from the presence of event handlers (such as
> `onclick`, `onhover`, etc.) attached to these elements. When NVDA detects
> these event handlers, it assumes that the element has some interactive
> functionality, leading to the "clickable" announcement. However, if these
> elements are not intended to be interactive, this can cause confusion.
>
> ### Other Potential Causes
>
> Besides event handlers, other factors that might cause NVDA to announce an
> element as clickable include:
> - Misuse of ARIA roles and properties.
> - Elements styled to look like buttons or links using CSS.
> - Scripts that dynamically change the interactivity of elements.
>
> ### WCAG 2.2 Compliance
>
> Regarding WCAG (Web Content Accessibility Guidelines) 2.2, this behavior
> touches on several criteria related to ensuring that web content is
> perceivable, operable, and understandable:
>
> - **WCAG 2.2 Criterion 1.3.1 - Info and Relationships**: Information,
> structure, and relationships conveyed through presentation can be
> programmatically determined or are available in text. If a non-interactive
> element is announced as "clickable," it might mislead users about the
> element's role.
>
> - **WCAG 2.2 Criterion 3.2.4 - Consistent Identification**: Components
> with the same functionality within a set of web pages are identified
> consistently. Announcing non-interactive elements as "clickable"
> inconsistently can lead to confusion.
>
> - **WCAG 2.2 Criterion 4.1.2 - Name, Role, Value**: For all user interface
> components, the name and role can be programmatically determined.
> Non-interactive elements should not have roles or properties that imply
> interactivity.
>
> While this specific issue is not directly called out in WCAG, it falls
> under the umbrella of ensuring a coherent and predictable experience for
> users relying on assistive technologies.
>
> ### Recommendations
>
> To avoid this issue and improve accessibility:
>
> 1. **Avoid Attaching Event Handlers to Non-Interactive Elements**: Only
> attach event handlers to elements that are meant to be interactive (e.g.,
> buttons, links).
>
> 2. **Use Appropriate ARIA Roles**: Ensure that only interactive elements
> are given roles that suggest interactivity (e.g., `button`, `link`).
>
> 3. **Test with Screen Readers**: Regularly test your website with NVDA and
> other screen readers to identify and resolve such issues.
>
> 4. **Provide Clear Instructions and Feedback**: Make sure that any
> interactive elements are clearly marked and provide feedback to users about
> their interactiveness.
>
> By following these practices, you can help ensure a more accessible and
> user-friendly experience for all users, including those using screen
> readers like NVDA.
>
> I hope this clarifies your concerns. If you have any more questions or
> need further assistance, feel free to ask.
>
> Thanks,
>
> Dean Vasile
>
>
> 617-799-1162
>
> > On Jun 25, 2024, at 10:32â¯AM, Sumit Patel < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > Hai all,
> >
> > I am writing to enquire about the behavior of the NVDA screen reader when
> > encountering non-interactive elements. I understand that NVDA announces
> > "clickable" for interactive elements which is very helpful for users when
> > the element's role has not been assigned. However I have observed
> instances
> > where NVDA announces even non-interactive elements as clickable on
> various
> > websites. My concern is that this can create a confusing and frustrating
> > experience for screen reader users especially encountered frequently
> > throughout a page. I've heard that this might be due to the presence of
> > event handlers attached to these elements. Is the presence of event
> > handlers the only reason behind NVDA announcing clickable for
> > non-interactive elements ? Additionally does this behavior violate any
> > criteria within WCAG 2.2 guideline ?
> >
> > I appreciate any clarification you can provide on this matter
> >
> > Thanks in Advance,
> > Sumit.
> > > > >
From: Patrick H. Lauke
Date: Tue, Jun 25 2024 11:24AM
Subject: Re: Enquiry regarding NVDA Clickable announcement and WCAG
← Previous message | Next message →
I'd say this is NVDA's behavior/choice, and yes it often caused by an
event listener in a parent/ancestor, rather than on the current element
itself - which, in cases where a site uses things like event delegation,
will cause a lot of noise/unnecessary "clickable" announcements.
But, this is an issue with NVDA, and not a WCAG failure (barring any
other situations where it's obvious that it fails because you didn't add
a role="..." or similar to an element that is *intended* to be
actionable/clickable).
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: jeffgutsell@fuse.net
Date: Wed, Jun 26 2024 2:27PM
Subject: Re: Enquiry regarding NVDA Clickable announcement and WCAG
← Previous message | Next message →
Hi All,
Can someone point me to any articles that discuss the impact of delegation in depth? I think I get the point but want to be sure.
Jeff Gutsell
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Tuesday, June 25, 2024 1:24 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Enquiry regarding NVDA Clickable announcement and WCAG
I'd say this is NVDA's behavior/choice, and yes it often caused by an event listener in a parent/ancestor, rather than on the current element itself - which, in cases where a site uses things like event delegation, will cause a lot of noise/unnecessary "clickable" announcements.
But, this is an issue with NVDA, and not a WCAG failure (barring any other situations where it's obvious that it fails because you didn't add a role="..." or similar to an element that is *intended* to be actionable/clickable).
P
--
Patrick H. Lauke
* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke
From: Laura Fathauer
Date: Thu, Jun 27 2024 8:41AM
Subject: Re: Enquiry regarding NVDA Clickable announcement and WCAG
← Previous message | No next message
Note that there is a setting to turn off the announcement of "clickable" in
NVDA, under "document formatting" then "elements".
Laura
On Tue, Jun 25, 2024 at 1:24â¯PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> I'd say this is NVDA's behavior/choice, and yes it often caused by an
> event listener in a parent/ancestor, rather than on the current element
> itself - which, in cases where a site uses things like event delegation,
> will cause a lot of noise/unnecessary "clickable" announcements.
>
> But, this is an issue with NVDA, and not a WCAG failure (barring any
> other situations where it's obvious that it fails because you didn't add
> a role="..." or similar to an element that is *intended* to be
> actionable/clickable).
>
> P
> --
> Patrick H. Lauke
>
> * https://www.splintered.co.uk/
> * https://github.com/patrickhlauke
> * https://flickr.com/photos/redux/
> * https://mastodon.social/@patrick_h_lauke
>
> > > > >