WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Multiple questions

for

From: Dean.Vasile@outlook.com
Date: Jun 11, 2024 4:42AM

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 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
> > > >