E-mail List Archives

Search E-mail List Archives for

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

From: Murphy, Sean
Date: Sun, Oct 24 2021 11:20PM
Subject: Voiceover bugs for Web
No previous message | Next message →

All,

Our accessibility team has noticed some bugs with Voiceover and Safari when using <div> and <span>. If a <span> is used within <divs> or other elements. The span tag is treated as a block element. Below are two scenario's we have discovered:


1. We have a design pattern for checkboxes which uses native HTML elements. Nested within the label is a <span> which has the visual description. Jaws for windows, NVDA, iOS Voiceover and Talk back android all treat this construct correctly. The screen reader announces the label and description, plus the state of the element in the correct order. Mac Voiceover says the label then "one more item". Aria-describedby could fix this issue if we applied it, but this is a unnecessary work around because all other screen readers work correctly.
2. On voiceover on iOS. If you use a <div> and <span nested. Such as <div> hello world <span> this is a fine place </span><div>. Voiceover announces the div text on the first swipe, then the span on the second swipe. Rather than reading the whole block of text. All other screen readers we have tested treat it as a single block of text as the <div> is a block element.
Other than making people aware of these strange issues, I am wondering if there is any resource out there which highlight these types of issues or a place to try and get them fixed.


Regards
Sean Murphy

Sean Murphy | Senior Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917
Submit an Engagement Accessibility form<link:%20https://confluence.tools.telstra.com/display/DCSYS/Request+Form>
Accessibility Single Source of Truth<https://confluence.tools.telstra.com/display/DCSYS/Accessibility>

From: glen walker
Date: Sun, Oct 24 2021 11:36PM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

For iOS (not sure if it works for Mac), you can use the *undocumented* text
role. It's not officially supported and support for it could drop at any
time, but it's been working for at least 7 years now.

<div role="text">hello world <span> this is a fine place</span></div>

This will read the entire <div> in one swipe.

On Sun, Oct 24, 2021 at 11:20 PM Murphy, Sean <
= EMAIL ADDRESS REMOVED = > wrote:

> All,
>
> Our accessibility team has noticed some bugs with Voiceover and Safari
> when using <div> and <span>. If a <span> is used within <divs> or other
> elements. The span tag is treated as a block element. Below are two
> scenario's we have discovered:
>
>
> 1. We have a design pattern for checkboxes which uses native HTML
> elements. Nested within the label is a <span> which has the visual
> description. Jaws for windows, NVDA, iOS Voiceover and Talk back android
> all treat this construct correctly. The screen reader announces the label
> and description, plus the state of the element in the correct order. Mac
> Voiceover says the label then "one more item". Aria-describedby could fix
> this issue if we applied it, but this is a unnecessary work around because
> all other screen readers work correctly.
> 2. On voiceover on iOS. If you use a <div> and <span nested. Such as
> <div> hello world <span> this is a fine place </span><div>. Voiceover
> announces the div text on the first swipe, then the span on the second
> swipe. Rather than reading the whole block of text. All other screen
> readers we have tested treat it as a single block of text as the <div> is a
> block element.
> Other than making people aware of these strange issues, I am wondering if
> there is any resource out there which highlight these types of issues or a
> place to try and get them fixed.
>
>
> Regards
> Sean Murphy
>
> Sean Murphy | Senior Digital System specialist (Accessibility)
> Telstra Digital Channels | Digital Systems
> Mobile: 0405 129 739 | Desk: (02) 9866-7917
> Submit an Engagement Accessibility form<link:%20
> https://confluence.tools.telstra.com/display/DCSYS/Request+Form>
> Accessibility Single Source of Truth<
> https://confluence.tools.telstra.com/display/DCSYS/Accessibility>
>
> > > > >

From: Murphy, Sean
Date: Mon, Oct 25 2021 2:19AM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

Glenn,

The point is you should not have to use such undocumented solutions. No other screen reader requires this on desktop or mobile. Using aria to address shortcoming of assistive technology isn't best practise. These types of band-aid solutions are not supporting the community of users who require this technology to access digital content. If any main stream vendor is stepping into the assistive technology space, then they need to be held accountable to making the assistive technology work for the end user and not have such strange bugs placing more effort on to other developers.

Likewise for browser vendors, there is a lot of ARIA usage which could quite easily be address by HTML and CSS. Reducing the crappy implementation of ARIA that exist now. Browser vendors from my point of view are using ARIA as a band-aid solution rather than expanding the specs to provide support for common patterns being used today.


Regards
Sean Murphy

Sean Murphy | Senior Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917
Submit an Engagement Accessibility form
Accessibility Single Source of Truth

From: glen walker
Date: Mon, Oct 25 2021 8:04AM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

Agreed. I typically let the screen reader do what it does and don't code
around the way it works, but sometimes the "owner" of the product requires
it so I was pointing out the hack to get around it. When I'm a contractor,
there's only so much "clout" that I can wield and even if I suggest the
code is technically accurate, if they don't like the UX of the SR, then I
give them workarounds. Thus I've used role=text when needed.

On Mon, Oct 25, 2021 at 2:19 AM Murphy, Sean <
= EMAIL ADDRESS REMOVED = > wrote:

> Glenn,
>
> The point is you should not have to use such undocumented solutions. No
> other screen reader requires this on desktop or mobile. Using aria to
> address shortcoming of assistive technology isn't best practise. These
> types of band-aid solutions are not supporting the community of users who
> require this technology to access digital content. If any main stream
> vendor is stepping into the assistive technology space, then they need to
> be held accountable to making the assistive technology work for the end
> user and not have such strange bugs placing more effort on to other
> developers.
>
> Likewise for browser vendors, there is a lot of ARIA usage which could
> quite easily be address by HTML and CSS. Reducing the crappy implementation
> of ARIA that exist now. Browser vendors from my point of view are using
> ARIA as a band-aid solution rather than expanding the specs to provide
> support for common patterns being used today.
>
>
>

From: Laurence Lewis
Date: Mon, Oct 25 2021 2:51PM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

The ios voiceover bug is known to Apple, and has been around for years. The
Text Role was invented by Apple to fix this exact purpose. It will likely
be around to stay and will most likely make it into the ARIA specification
at some point, and is safe to use now.

A common issue caused by this bug are links that include either an image
with alt text or a span with offscreen screen reader only text that informs
a link opens in a new tab placed inside the link. iOS / VoiceOver treats it
as two block elements.

Laurence Lewis
Accessibility Senior Specialist

From: David Engebretson Jr.
Date: Mon, Oct 25 2021 3:30PM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

Interesting. Is it iOS/Voiceover that treats it as two block elements or is it the Safari browser?

Divs and spans aren't semantic elements. I always thought the purpose of them was to do things inside of semantic elements as to not disrupt the flow of the content. Maybe I need to change my thinking...

Thanks for the food for thought!
David

From: glen walker
Date: Mon, Oct 25 2021 6:58PM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

> It will likely be around to stay and will most likely make it into the
> ARIA specification
> at some point, and is safe to use now.
>

That might be a bit generous. Until something is in the spec, I would not
consider it safe to use. There was a text role batted around for a while
by the ARIA committee but it was decided to not include it in the spec. It
*might* make it in one day but unless you're on the committee lobbying for
it, there's no guarantee it'll ever be there.

https://www.w3.org/WAI/ARIA/track/issues/435
https://lists.w3.org/Archives/Public/wai-xtech/2011Apr/0007.html

From: David Engebretson Jr.
Date: Mon, Oct 25 2021 10:40PM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

Lots of history in there Glen, thanks for sharing!

From: Birkir R. Gunnarsson
Date: Tue, Oct 26 2021 3:44AM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

A <span> is a semantically neutral inline element, no reason to put it
on its own line, especially when its part of a focusable block level
element (like a link).
There is no need for a text role to make that happen. Even if it were,
the native HTML equivalent would be the <span> element.

I spoke up against the text role at the time, though the use case I
didn't like was to use it on image elements.

You could try role="none" on the <span> to see if it changes anything?
It's worth a try certainly.


On 10/26/21, David Engebretson Jr. < = EMAIL ADDRESS REMOVED = > wrote:
> Lots of history in there Glen, thanks for sharing!
>
>
>

From: James Nurthen
Date: Tue, Oct 26 2021 9:12AM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

+1 Glen.
As chair of the ARIA WG I can state it is unlikely that role="text" will
ever make it into the spec - there were too many objections. It got much
closer when it was renamed to role="static" so IMO if it ever does make it
then it will be with a different name than role="text"

Regards,|
James

On Mon, Oct 25, 2021 at 5:59 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> > It will likely be around to stay and will most likely make it into the
> > ARIA specification
> > at some point, and is safe to use now.
> >
>
> That might be a bit generous. Until something is in the spec, I would not
> consider it safe to use. There was a text role batted around for a while
> by the ARIA committee but it was decided to not include it in the spec. It
> *might* make it in one day but unless you're on the committee lobbying for
> it, there's no guarantee it'll ever be there.
>
> https://www.w3.org/WAI/ARIA/track/issues/435
> https://lists.w3.org/Archives/Public/wai-xtech/2011Apr/0007.html
> > > > >

From: glen walker
Date: Tue, Oct 26 2021 11:10AM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

Going back to the original issue, it used to be that any nested elements in
a link would cause VoiceOver to stop at each element. But that was changed
in some version of ios 12 so that inline elements didn't do that anymore.

For example, the following used to stop at each span element:

<a href='.'>test of <span style="color:red">inline</span> elements and
<span style="font-weight: bold;">bold</span> formatting </a>

but now it treats it as one voiceover stop.

However, if those spans were divs (block element), then voiceover still
stops at each one.

<a href='.'>test of <div style="color:red">inline</div> elements and <div
style="font-weight: bold;">bold</div> formatting </a>

To get around that problem without using the text role, you can make the
divs inline elements (although that will affect the formatting).

<a href='.'>test of <div style="color:red; display: inline;">inline</div>
elements and <div style="font-weight: bold;display: inline;">bold</div>
formatting </a>

From: Laurence Lewis
Date: Tue, Oct 26 2021 3:03PM
Subject: Re: Voiceover bugs for Web
← Previous message | Next message →

Thanks for the comments and opinions on the Text Role.

I had heard that it was safe to use and still under discussion to be
included in the ARIA Spec. The role is flagged for further discussion in
the ARIA 1.4 Milestone as noted by "*jnurthen added this to the ARIA 1.4
milestone on Mar 5*" on the long, but interesting discussion "Consider
early re-add of role=text #870 <https://github.com/w3c/aria/issues/870>".

The Text Role works to fix (hack) the iOS VoiceOver bug (text-splitting) as
intended. Thus would it be fair to state that it is safe to use now, but
may not be in the future, depending on if it ever becomes a supported Role
in the ARIA Spec, regardless of what it is named. :-)

The intended use of the Text Role is demonstrated by Paul J Adams 'VoiceOver
iOS Multiple Focus of Internal Elements Bug and Hack Fix
<https://pauljadam.com/demos/voiosmultifocusbug.html>'.

I look forward to a time when role Text is confirmed supported, or not, by
the ARIA WG.


Laurence Lewis
Accessibility Senior Specialist

From: David Engebretson Jr.
Date: Tue, Oct 26 2021 7:14PM
Subject: Re: Voiceover bugs for Web
← Previous message | No next message

The only thing I put on span is a visually-hidden class or a lang attribute.

I tend to use non-semantic elements as infrequently as possible. I also tend to use roles as infrequently as possible.

*pom poms on* Go Semantic HTML!*pom poms off*

Peace,
David