Open Bug 1730868 Opened 3 years ago Updated 3 years ago

TextLeafPoint: Better handling for inline-block for line boundaries


(Core :: Disability Access APIs, task)





(Reporter: Jamie, Unassigned)



Inline-block elements are a conundrum for a11y line boundaries because they contain their own idea of lines. According to an inline-block element, the first element inside it begins a new line. On the other hand, from the perspective of the containing block element, it doesn't begin a new line because it's placed within a line in its enclosing block element. For example:
This should be considered one single line. Currently, TextLeafPoint treats the button as a separate line because the two frames have different enclosing blocks and line numbers within those.
I'm not quite sure how to deal with this. I think we might have to walk outside of inline-block elements and work from there.

A more complicated example is this:
Currently, HyperTextAccessible's handling of this depends on what Accessible you query. That is, if you query the block, the inline-block is included on the same line as the other inline content. If you query the inline-block, you see the separate lines inside it.
That behaviour is weird for TextLeafPoint because it means you'll get different line boundaries depending on where you search from.

For now, I think we should deal with the first example and figure out how to handle the second in a follow-up, especially given that HyperTextAccessible doesn't handle the second particularly well right now either.

No longer blocks: a11y-ctw
You need to log in before you can comment on or make changes to this bug.