E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: jeffgutsell@fuse.net
Date: Fri, Mar 15 2024 12:04PM
Subject: VoiceOver with Safari on iOS error on ALT text null value
No previous message | Next message →

Hi All,

I recently upgraded my iPhone to iOS 17.4 and discovered that VoiceOver now
is speaking characters that should be silent. I am wondering if others have
noticed something like this, or perhaps I should use a different technique.

On buttons that control popup menus, I use the following CSS property:

content: "↓" / "";

The last part of that statement should cause the “down arrow” character to
be treated as null alt text. But VoiceOver speaks it as regular text.
Previous versions of VoiceOver and Safari did not do this.



Jeff Gutsell





Any suggestions?

From: Jano Llorca Lis
Date: Fri, Mar 15 2024 12:41PM
Subject: Re: VoiceOver with Safari on iOS error on ALT text null value
← Previous message | Next message →

Hi Jeff,

For the issue you're encountering with VoiceOver on iOS 17.4, it seems like
the CSS content property you're using to control the display of the "down
arrow" character for popup menus is being interpreted differently than in
previous versions. The intention behind content: "↓" / ""; is
understandable, but it appears that the method for making this character
"silent" to screen readers like VoiceOver is no longer effective.

One approach to ensure that decorative characters or icons do not interfere
with screen reader output is to leverage ARIA (Accessible Rich Internet
Applications) attributes, specifically aria-hidden="true" for elements that
should be hidden from screen reader users. This attribute tells screen
readers and other assistive technologies to ignore the element it's applied
to, effectively making it "silent".

Given the situation described, a more robust solution might involve the
following adjustments:

- Use ARIA Hidden Attribute: Apply aria-hidden="true" to the element
containing the decorative character or icon. This ensures it is ignored by
screen readers:
<span aria-hidden="true">↓</span>

- Provide Accessible Name When Necessary: If the button or element has an
important role (such as triggering a dropdown menu), ensure it has an
accessible name using aria-label or aria-labelledby. This provides screen
reader users with the necessary context while keeping decorative content
silent:
<button aria-label="Open menu">
<span aria-hidden="true">↓</span> Menu
</button>

- Review Implementation for Semantic HTML: Whenever possible, use semantic
HTML elements and attributes to convey meaning and functionality. For
buttons controlling popup menus, ensure the button element is used and that
the state (expanded or collapsed) is communicated via aria-expanded:
<button aria-label="Open menu" aria-expanded="false">
Menu <span aria-hidden="true">↓</span>
</button>

This adjustment not only helps with the current issue related to the iOS
update but also aligns with best practices for web accessibility, making
your content more accessible to users with disabilities.

Regarding the content property method you've been using, it's important to
note that CSS generated content is not consistently announced by all screen
readers and can lead to variability in user experience, especially after
system updates or changes in assistive technology behavior. Focusing on
ARIA attributes and semantic HTML will provide a more stable and accessible
experience across different devices and assistive technologies.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden


Regards,

*Jano Llorca*
Consultor SEO - SEM - Social Ads
UX - UI - Diseño y Accesibilidad Web

Tlf: 673 346 726
= EMAIL ADDRESS REMOVED =

<https://ilumina-agencia-consultora-seo.business.site/>


El vie, 15 mar 2024 a las 19:04, < = EMAIL ADDRESS REMOVED = > escribió:

> Hi All,
>
> I recently upgraded my iPhone to iOS 17.4 and discovered that VoiceOver now
> is speaking characters that should be silent. I am wondering if others have
> noticed something like this, or perhaps I should use a different
> technique.
>
> On buttons that control popup menus, I use the following CSS property:
>
> content: "↓" / "";
>
> The last part of that statement should cause the “down arrow” character to
> be treated as null alt text. But VoiceOver speaks it as regular text.
> Previous versions of VoiceOver and Safari did not do this.
>
>
>
> Jeff Gutsell
>
>
>
>
>
> Any suggestions?
>
>
>
> > > > >

From: jeffgutsell@fuse.net
Date: Fri, Mar 15 2024 1:34PM
Subject: Re: VoiceOver with Safari on iOS error on ALT text nullvalue
← Previous message | No next message

Hi Jano,
Thanks for the detailed response. The approach looks great. I will start working on this Monday.
I have been using aria-controls and aria-expanded for years. Your idea will be an easy change.

Jeff

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jano Llorca Lis
Sent: Friday, March 15, 2024 2:42 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] VoiceOver with Safari on iOS error on ALT text null value

Hi Jeff,

For the issue you're encountering with VoiceOver on iOS 17.4, it seems like the CSS content property you're using to control the display of the "down arrow" character for popup menus is being interpreted differently than in previous versions. The intention behind content: "↓" / ""; is understandable, but it appears that the method for making this character "silent" to screen readers like VoiceOver is no longer effective.

One approach to ensure that decorative characters or icons do not interfere with screen reader output is to leverage ARIA (Accessible Rich Internet
Applications) attributes, specifically aria-hidden="true" for elements that should be hidden from screen reader users. This attribute tells screen readers and other assistive technologies to ignore the element it's applied to, effectively making it "silent".

Given the situation described, a more robust solution might involve the following adjustments:

- Use ARIA Hidden Attribute: Apply aria-hidden="true" to the element containing the decorative character or icon. This ensures it is ignored by screen readers:
<span aria-hidden="true">↓</span>

- Provide Accessible Name When Necessary: If the button or element has an important role (such as triggering a dropdown menu), ensure it has an accessible name using aria-label or aria-labelledby. This provides screen reader users with the necessary context while keeping decorative content
silent:
<button aria-label="Open menu">
<span aria-hidden="true">↓</span> Menu </button>

- Review Implementation for Semantic HTML: Whenever possible, use semantic HTML elements and attributes to convey meaning and functionality. For buttons controlling popup menus, ensure the button element is used and that the state (expanded or collapsed) is communicated via aria-expanded:
<button aria-label="Open menu" aria-expanded="false">
Menu <span aria-hidden="true">↓</span> </button>

This adjustment not only helps with the current issue related to the iOS update but also aligns with best practices for web accessibility, making your content more accessible to users with disabilities.

Regarding the content property method you've been using, it's important to note that CSS generated content is not consistently announced by all screen readers and can lead to variability in user experience, especially after system updates or changes in assistive technology behavior. Focusing on ARIA attributes and semantic HTML will provide a more stable and accessible experience across different devices and assistive technologies.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden


Regards,

*Jano Llorca*
Consultor SEO - SEM - Social Ads
UX - UI - Diseño y Accesibilidad Web

Tlf: 673 346 726
= EMAIL ADDRESS REMOVED =

<https://ilumina-agencia-consultora-seo.business.site/>


El vie, 15 mar 2024 a las 19:04, < = EMAIL ADDRESS REMOVED = > escribió:

> Hi All,
>
> I recently upgraded my iPhone to iOS 17.4 and discovered that
> VoiceOver now is speaking characters that should be silent. I am
> wondering if others have noticed something like this, or perhaps I
> should use a different technique.
>
> On buttons that control popup menus, I use the following CSS property:
>
> content: "↓" / "";
>
> The last part of that statement should cause the “down arrow”
> character to be treated as null alt text. But VoiceOver speaks it as regular text.
> Previous versions of VoiceOver and Safari did not do this.
>
>
>
> Jeff Gutsell
>
>
>
>
>
> Any suggestions?
>
>
>
> > > archives at http://webaim.org/discussion/archives
> >