E-mail List Archives
Thread: Multiple questions
Number of posts in this thread: 2 (In chronological order)
From: megha patangi
Date: Mon, Jun 10 2024 11:37PM
Subject: Multiple questions
No previous message | Next message →
Hello Web Aim Team,
I have following different questions, in very different scenarios:
1. We have used input box in one of our very complex widget for better
focus management. this is just in code but not available for anyone to use,
neither visible on screen. since this is interactive element we cannot use
aria-hidden on it.
so what could be the best way to hide it so that it does not effect user
adversely and also is no longer flagged in automated test?
2. Secondly, I have a use case where on a single UI there may happen to
witness multiple dynamic changes in parallel, like timer is running,
notifications are coming, articles are getting updated and many more. if we
give them all aria-live even with right value of assertive/ polite as per
their priority, but still there is too much to listen and definitely only
the one assertive will get heard, others will suppress. on top of it,
screen is becoming too noisy.
is there any idea/ suggestion/ technique with which such scenario can be
handled better?
3. Finally, if we have a very visual based component say for example google
maps and they are not end to end accessible then what should be our
approach for it. I have a similar component which has lot to consume
visually. it is like a huge organization chart with various nodes and to
perceive right information whole chart needs to be looked together to get
the relationship between two nodes.
Even we make these keyboard accessible, but for a screen reader they might
be able to navigate but too difficult to perceive same amount of
relationship information.
Any suggestions on what best can be done here? Any maximum acceptable
approach which is useful as well as passes WCAG?
Regards,
Megha
From: Dean.Vasile
Date: Tue, Jun 11 2024 4:42AM
Subject: Re: Multiple questions
← Previous message | No next message
Dear Mega,
* Hidden Input Box:
* Use display:none or visibility:hidden in CSS to hide the input box.
* These styles prevent the input box from affecting layout or screen readers.
* Automated tests may still flag it, but this can be addressed by adding an attribute like data-test="ignore".
* Multiple Dynamic Updates:
* Use aria-live="polite" for most updates, reserving aria-live="assertive" for critical alerts.
* Prioritize updates and only announce the most important ones.
* Consider a notification center where users can review less urgent updates.
* Complex Visual Components:
* Provide a text summary of the key information conveyed by the visual component.
* If possible, offer alternative formats (e.g., tabular data) for better accessibility.
* Consider a simplified version of the component for screen reader users.
* Acknowledge limitations in accessibility and provide clear instructions for users who may need assistance.
Dean Vasile
617-799-1162
Dean Vasile
617-799-1162
> On Jun 11, 2024, at 1:37 AM, megha patangi < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hello Web Aim Team,
>
> I have following different questions, in very different scenarios:
>
> 1. We have used input box in one of our very complex widget for better
> focus management. this is just in code but not available for anyone to use,
> neither visible on screen. since this is interactive element we cannot use
> aria-hidden on it.
> so what could be the best way to hide it so that it does not effect user
> adversely and also is no longer flagged in automated test?
>
> 2. Secondly, I have a use case where on a single UI there may happen to
> witness multiple dynamic changes in parallel, like timer is running,
> notifications are coming, articles are getting updated and many more. if we
> give them all aria-live even with right value of assertive/ polite as per
> their priority, but still there is too much to listen and definitely only
> the one assertive will get heard, others will suppress. on top of it,
> screen is becoming too noisy.
> is there any idea/ suggestion/ technique with which such scenario can be
> handled better?
>
> 3. Finally, if we have a very visual based component say for example google
> maps and they are not end to end accessible then what should be our
> approach for it. I have a similar component which has lot to consume
> visually. it is like a huge organization chart with various nodes and to
> perceive right information whole chart needs to be looked together to get
> the relationship between two nodes.
> Even we make these keyboard accessible, but for a screen reader they might
> be able to navigate but too difficult to perceive same amount of
> relationship information.
> Any suggestions on what best can be done here? Any maximum acceptable
> approach which is useful as well as passes WCAG?
>
> Regards,
> Megha
> > > >