A problem when using the latest version of Webkit with the Voiceover screenreader. If I go to the following URL and want to find the link "Run web client" I can not find it. However if I open the same page in Safari 5 (the latest version) the link is possible to find. Here is the steps to reproduce the error: 1. Go to the URL mentioned above. 2. Activate Voiceover by typing Command-F5 (if some one uses a laptop add the FN-key to the keystroke). 2. Press CTRL-option and the letter u. 3. Press the right arrow until you see or hear the word: Link. 4. Type: Ru (do this quickly) 5. You'll see that the link can't be found. Instead Voiceover detects the link named Features. 6. Try to open the Safari browser and do the same steps (1-5) NOTE: You need to hit the escape key to exit the list of links (or as it is called in Voiceover the webroter).
what URL are you going to.. i don't see it listed here
rdar://8859923
at the end of the the top <ul> is an iframe, that for some reason references the main web page, so VoiceOver gets into a loop
part of the problem is that the iframe had a title tag on it, causing it to NOT be ignored, which meant the hierarchy was not created correctly for the sub-frame
Here are the issues related 1) WebDynamicScrollBars should no longer be returned as an accessible item (since its taken care of by AccessibilityScrollView) 2) accessibilityIsIgnored, cannot query if the helpText is empty, before checking it it's an attachment (in this case the help text (title) was not empty, so the wrong element was being returned) 3) the hit point needs to be altered when hit test within the iframe again to be offset correctly
Chris, The issue which I talked about is not only on that site. I tried it e.g. on my Facebook mobile-site (which I prefer to use) and the same problem showed up. Voiceover was not able to track some links however I could find them by scrolling down the page. However it worked until the update which came out a few days ago therefor I guess this might be a webkit related issue? I have not been able to get the same issue in Safari however I tried on the same page and Voiceover finds the link exactly as it shell. So is the issue below only for the URL I wrote earlier or a more general fix? (In reply to comment #5) > Here are the issues related > 1) WebDynamicScrollBars should no longer be returned as an accessible item (since its taken care of by AccessibilityScrollView) > 2) accessibilityIsIgnored, cannot query if the helpText is empty, before checking it it's an attachment (in this case the help text (title) was not empty, so the wrong element was being returned) > 3) the hit point needs to be altered when hit test within the iframe again to be offset correctly
Created attachment 79020 [details] Patch
Comment on attachment 79020 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=79020&action=review > Source/WebCore/accessibility/AccessibilityObject.cpp:1022 > + IntRect frameRect = widget->frameRect(); > + IntPoint newPoint = point; > + newPoint.setX(point.x() - frameRect.x()); > + newPoint.setY(point.y() - frameRect.y()); > + return axObjectCache()->getOrCreate(widget)->accessibilityHitTest(newPoint); This can be written without doing X and Y separately: IntPoint newPoint = point - widget->frameRect().location(); Or even: return axObjectCache()->getOrCreate(widget)->accessibilityHitTest(point - widget->frameRect().location()); > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:1888 > + // This should be the last check > + if (!helpText().isEmpty()) > + return false; > > - return !m_renderer->isListMarker() && !isWebArea(); > + return true; If it is important that the helpText check be last then you *could* write it like this: return helpText().isEmpty(); Unless you think that’s less clear. Also, we prefer comments that are in sentence style. Also, the comment needs to say why the helpText check should be last. The general rule of thumb is that comments say why and the code itself says what.
http://trac.webkit.org/changeset/76044