Last modified: 2014-06-24 21:04:17 UTC
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 bug 18338 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.
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
(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?
