1951067 - Extraneous whitespace text leaf nodes exposed in the accessibility tree that aren't rendered visibly

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

I discovered this as part of my investigation of the bogus name change event being fired in bug 1931302, as well as working on UI Automation text tests.

Test case:

data:text/html,<span>a</span> <span hidden>b</span>

This results in a text node for "a", followed by a text node containing " ", except that the second text node is off-screen with a width of 0. If you were to unhide the "b" span, that " " text node would be visibly rendered because it needs to separate the nodes. But if a white space text node has a width of 0, I think it's not semantically relevant and we should prune it.

Comment 1

[James Teh [:Jamie]]

Attachment: Bug 1951067: Don't include invisible whitespace text nodes in the accessibility tree.

Comment 2

[James Teh [:Jamie]]

Morgan, I'd be interested to know if this fixes the particular test case referenced in bug 1931302 comment 0 on Mac. It's obviously not going to deal with cases where the name is really changed, but I question how common that is (or should be anyway).

Comment 3

[Morgan Reschenberg [:morgan]]

(In reply to James Teh [:Jamie] from comment #2)

Morgan, I'd be interested to know if this fixes the particular test case referenced in bug 1931302 comment 0 on Mac. It's obviously not going to deal with cases where the name is really changed, but I question how common that is (or should be anyway).

This does fix most of the issue! The only remaining problem is VO now draws the bounds incorrectly after the switch is activated (this is true whether you press it from on to off or vice versa). Instead of drawing the bounds around the entire group (switch label + switch control + on/off label), bounds are drawn over the <input> which has opacity:0;. Not sure there's much to do here because the input is the switch control, but Chrome doesn't seem to have this problem. I assume it would draw them across the entire group because the group is what I focus to activate the switch :(

Should I morph the bug I'm working on to take on that bounds issue?

Comment 4

[James Teh [:Jamie]]

(In reply to Morgan Reschenberg [:morgan] from comment #3)

This does fix most of the issue! The only remaining problem

We may want to open a bug to deal with the simultaneous name + value change problem, even if we decide not to fix it right now.

VO now

Now after this patch? I don't quite follow why this would have changed the bounds reported. 😕

draws the bounds incorrectly after the switch is activated (this is true whether you press it from on to off or vice versa). Instead of drawing the bounds around the entire group (switch label + switch control + on/off label), bounds are drawn over the <input> which has opacity:0;. Not sure there's much to do here because the input is the switch control, but Chrome doesn't seem to have this problem. I assume it would draw them across the entire group because the group is what I focus to activate the switch :(

I'm confused. If the input is the thing with role="switch", why would you focus the group to activate the switch? I don't understand how Chrome would know to the draw the bounds around the group unless the group is itself focusable and has role="switch". But I think I'm missing something here.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/43d3dabf7fe9
Don't include invisible whitespace text nodes in the accessibility tree. r=morgan

Comment 6

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/43d3dabf7fe9

Comment 7

[Morgan Reschenberg [:morgan]]

<fieldset>
            <legend>Accessibility Preferences</legend>
            <label>
              <span class="label">Reduced motion</span>
              <input id="id-switch-1" type="checkbox" role="switch">
              <span class="state">
                <span class="container">
                  <span class="position"> </span>
                </span>
                <span class="on" aria-hidden="true">On</span>
                <span class="off" aria-hidden="true">Off</span>
              </span>
            </label>

            <label>
              <span class="label">Show captions</span>
              <input id="id-switch-2" type="checkbox" role="switch">
              <span class="state">
                <span class="container">
                  <span class="position"> </span>
                </span>
                <span class="on" aria-hidden="true">On</span>
                <span class="off" aria-hidden="true">Off</span>
              </span>
            </label>
          </fieldset>

Here's the markup for reference. I think the issue is the <input role="switch"> is styled with opacity:0; which effectively hides it from view, but not from a11y clients (so VO focuses it instead of the switch (id="state") SVG), which makes it look like VO is doing something wrong.

In retrospect, I think this might be what is causing safari's weird focus behaviour; they might be marking invisible items (opacity:0) as ignored, and then when they try to send VO focus there, it gets confused/trapped and throws focus to a nowhere zone.

Anyway, I'm not sure there's anything to do here, I think the example is not ideal.
We now have better behaviour than Chrome in one respect -- you can focus the switch's label with VO and activate it, which will voice the switch state and toggle it. In Chrome activating the label does nothing, despite VO announcing it as 'clickable'.

Comment 8

[Morgan Reschenberg [:morgan]]

This might've not been an issue before because VO could've been responding to the title change event by focusing the label, which wraps the switch itself. Not sure, but the previous behaviour was such that toggling the switch by pressing the label kept the entire label group focused.

Comment 9

[James Teh [:Jamie]]

Hmm. I still don't understand why there should have been any bounds drawing change here at all. That said, it's very odd that the role="switch" has opacity: 0 without having the visual part of the switch be layered over the top. IMO, that's just bad authoring. It's probably okay for it to not draw bounds around the label, but it should at least be drawing them around the visual switch indicator. All of this is to say that I agree with you: "I'm not sure there's anything to do here, I think the example is not ideal."