Bug 132349 – AX: [ATK] text inside span block in a block not accessible

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Jarek Czekalski]

<div>
<div>Before</div>
<a style="display:block;" href="xref">
<span style="display:block;">Span</span>
</a>
<div>After</div>
</div>

In this example Span text is not accessible. The link is not ATK_TEXT. This is related to bug #130941 and these 2 bugs together make yelp gnome documentation partially inaccessible.

Test case to come soon.

[Radar WebKit Bug Importer]

<rdar://problem/16759234>

[Jarek Czekalski]

Created attachment 232681 [details]
fix for span block v1.00

When atk interfaces are considered getInterfaceMaskFromObject (accessibility/atk/WebKitAccessibleWrapperAtk.cpp), then all divs are given (roleIsTextType). Seems like all links may also be given this interface. I don't see any counterexample. So this is what the one-liner patch does.

The patch also tested on 2.4 branch.

[Mario Sanchez Prada]

Comment on attachment 232681 [details]
fix for span block v1.00

View in context: https://bugs.webkit.org/attachment.cgi?id=232681&action=review

The patch looks good to me, but I have a suggestion to improve the test before landing. See below...

> LayoutTests/platform/gtk/accessibility/text-in-span-block-in-a-block.html:14
> +    <span style="display:block;">text1</span>

I think it would be interesting to place some text before and after the <span> *and* inside the scope of the <a> elements (for all the three cases), and then check that the full text (including the text inside the span and those 'before' and 'after' bits) will be returned when calling element.stringValue.

The purpose of this suggestion  is to ensure that the implementation of AtkText for those links whose children are not inline (because of the 'display: block' thing) is still returning the full 'flattened' text for all the block children (the 'before' and 'after' will be part of generated block elements) inside of it.

Other than this (and assuming that that extended version of the test will still pass), I don't have any other comment on the patch.

[Jarek Czekalski]

Created attachment 232723 [details]
fix for span block v1.01

Hi Mario

>I think it would be interesting to place some text before and after [...]

There are countless configurations possible. I chose three of them and I hope this set is sufficient for you :)
Small rebuild of test script was needed to keep it friendly.

Thanks for the immediate review!

[Mario Sanchez Prada]

Comment on attachment 232723 [details]
fix for span block v1.01

(In reply to comment #4)
> Created an attachment (id=232723) [details]
> fix for span block v1.01
> 
> Hi Mario
> 
> >I think it would be interesting to place some text before and after [...]
> 
> There are countless configurations possible. I chose three of them and I hope this set is sufficient for you :)
> Small rebuild of test script was needed to keep it friendly.
> 

Hi Jarek, apologies for taking so much time to review this (it fell off my radar somehow), and thanks for considering my comments and incorporating them in the new patch. LGTM now

[WebKit Commit Bot]

Comment on attachment 232723 [details]
fix for span block v1.01

Clearing flags on attachment: 232723

Committed r169936: <http://trac.webkit.org/changeset/169936>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.