Page MenuHomePhabricator

After introduction of WAI ARIA roles, VoiceOver is extremely slow
Closed, DeclinedPublic

Description

I'm reporting this for a blind person, who sent an e-mail to info-de@wikipedia.org. He uses Voice-Over on his Mac as his screenreader software (using Safari as browser).

He reports, that after loading a large article, Voice-Over and/or Safari use a lot of CPU power and the PC hangs for seconds and even after this, voice-over reacts very slowly. He reports that this problem occurs since 22nd of November, the day the changes of T20338 became live on de.wikipedia.

With the introduction of WAI-ARIA groups, the whole article is one group for Voice-Over. Before, each paragraph was an own group. Most likely this screenreader software can't handle such large groups like a very long wikipedia article.

For the moment, he can't really use wikipedia.


Version: unspecified
Severity: major
OS: Mac OS X 10.7
Platform: Macintosh
See Also:
https://bugs.webkit.org/show_bug.cgi?id=119694

Details

Reference
bz42394

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:54 AM
bzimport set Reference to bz42394.
bzimport added a subscriber: Unknown Object (MLST).

Strange, can some reproduce this bug ?

Christian: Could you provide an exact testcase (link to "a large article") please?

(In reply to comment #2)
I have no mac so I can't reproduce this bug and work on it. Can someone try to reproduce this bug?

(In reply to comment #2)

Christian: Could you provide an exact testcase (link to "a large article")
please?

The person did not mention any particular article, but it seems, that the german main page is fine, but most of the featured articles are too long, like
http://de.wikipedia.org/wiki/Deutschland

kamikaze28 wrote:

(In reply to comment #4)

(In reply to comment #2)

Christian: Could you provide an exact testcase (link to "a large article")
please?

The person did not mention any particular article, but it seems, that the
german main page is fine, but most of the featured articles are too long, like
http://de.wikipedia.org/wiki/Deutschland

I'm the son of the original reporter of this bug and I provided Christian Thiele with the additional information.

I opened http://de.wikipedia.org/wiki/Deutschland on my MacBook Pro (2.66 GHz Intel Code 2 Duo) on Lion (10.7.5) with Safari 6.0.2 (7536.26.17) with active VoiceOver and it took roundabout 20 seconds after loading and rendering the article before Safari was responsive to VoiceOver again. Switching to the main section of the page (namely, the article) again takes ~10 seconds and proclaims itself to be a group of 811 objects. Entering and navigating within this group is only possible with 1 to 2 seconds of delay between a keystroke and its reaction.

Potential regression from bug 18338.
As Tpt doesn't have a Mac I'm not sure how to proceed here.

I can reproduce this. It's caused by the 'indexing' of the region I suspect and suddenly there is one huge region around the other regions, and it just takes long before VO is ready to respond again. I presume this is an oversight in the Safari+VO implementation.

I'm not sure if there is really a good solution to this from our side (other than removing, which is a bad idea if you ask me). I suggest complaining (loudly) at Apple. I'll also file a ticket with the Webkit team.

DJ: Thanks for investigating this!

I don't think there's much we can do on our side so I'll lower priority there.
Looks like this needs fixing in Safari/WebKit but no progress on the upstream ticket in https://bugs.webkit.org/show_bug.cgi?id=119694 :(

Might even be a "CANNOT FIX" ticket for us here?

TheDJ set Security to None.
TheDJ moved this task from Backlog to Reported Upstream on the Upstream board.

If this is an issue of screen readers struggling with a single too-big landmark/region, could wrapping output in <section>-like <div>s do the trick?

From one big region:

<p>
    <b>Breakfast</b> is an article found on Wikipedia.
</p>
<div id="toc" class="toc">...</div>
<h2>
    <span class="mw-headline" id="Fruits">Fruits</span>
    <span class="mw-editsection">...</span>
</h2>
<p>Sometimes Wikipedians have fruit for breakfast...</p>
<h3>
    <span class="mw-headline" id="Bananas">Bananas</span>
    <span class="mw-editsection">...</span>
</h3>
<p>Bananas are a type of fruit...</p>
<h3>
    <span class="mw-headline" id="Raisins">Raisins</span>
    <span class="mw-editsection">...</span>
</h3>
<p>Raisins are a dried type of fruit...</p>

To five smaller regions (one of which is also a landmark):

<div role="region" id="lead">
    <p>
        <b>Breakfast</b> is an article found on Wikipedia.
    </p>
</div>
<div role="navigation" id="toc" class="toc">...</div>
<div role="region" id="Fruits">
    <div class="mw-headline">
        <h2>Fruits</h2>
        <div class="mw-editsection">...</div>
    </div>
    <p>Sometimes Wikipedians have fruit for breakfast...</p>
</div>
<div role="region" id="Bananas">
    <div class="mw-headline">
        <h3>Bananas</h3>
        <div class="mw-editsection">...</div>
    </div>
    <p>Bananas are a type of fruit...</p>
</div>
<div role="region" id="Raisins">
    <div class="mw-headline">
        <h3>Raisins</h3>
        <div class="mw-editsection">...</div>
    </div>
    <p>Raisins are a dried type of fruit...</p>
</div>

WebAIM uses exactly this structure on their pages, and I've seen other big sites like Microsoft's help pages doing similar things with div wrappers.

Oh good, looks like there's already work being done on this!

T114072 <section> tags for MediaWiki sections

@MattFitzpatrick yeah, that would probably help. But such changes are rather complex to execute throughout the platform.

Volker_E renamed this task from After introduction of WAI-ARIA roles, Voice-Over is extremely slow to After introduction of WAI ARIA roles, VoiceOver is extremely slow.Apr 6 2016, 5:09 AM

This task has been filed more than 7 years ago and correctly tagged “upstream”. VoiceOver has ever since been used without any further updates on this task or upstream. Closing it, as we need to focus our efforts on most pressing issues which are in our hand. If the browser accessibility tree or it's interpretation by up-to-date VoiceOver are a problem, let's reference this task.