Open Bug 1655503 Opened 4 years ago Updated 1 month ago

Improve accessibility of <input type="search"> layout

Categories

(Core :: Layout, task)

Product:
Core
Component:
Layout
Type:
task

Tracking

()

Project Flags:
Accessibility Severity s2

People

(Reporter: ntim, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Would be nice for a11y.

Making this more generic. IIRC what was told, I think what's wanted here is mostly implementing the Esc keyboard shortcut to clear the value (consistent with chromium), which would potentially make the label/tooltip unnecessary.

Maybe there's something else I'm missing though.

Summary: Add an aria-label or tooltip to <input type="search"> clear button → Improve accessibility of <input type="search"> layout

As well as the escape key, at least for now, the clear button also needs to be hidden from the a11y tree. Otherwise, this breaks text interaction for screen readers. This is similar to bug 1609394. Chrome does the same.

If this same implementation is going to be used on mobile, that's not ideal because mobile users then can't access the clear text button. I don't currently have a solution for this problem. I'm also not sure what Chrome does on mobile for this case.

Marking access-s2 because this breaks the feature for screen reader users and definitely needs to be addressed before shipping.

Keywords: access
Whiteboard: [access-s2]

Yeah, we should hide it with aria-hidden=true like this:
https://searchfox.org/mozilla-central/rev/a12c2c2e59c92d8f969d8f3f290ab16919449c9d/layout/forms/nsTextControlFrame.cpp#370

I did the same for the Show Password button I'm adding in bug 502258.

Accessibility Severity: --- → s2
Whiteboard: [access-s2]

Given this is for a not-shipping by default thing, probably shouldn't be an access-s2?

Flags: needinfo?(jteh)

It's a little tricky. On one hand, yes, sure, it's not shipping, so it's not currently an access-s2 for users. On the other hand, if we do plan to ship it, it will become an access-s2. The concern is that if we drop it to access-s3 and then we later decide to ship this, folks might not realise that this is absolutely a ship blocker. This is one of the few situations where it's reasonable for a feature to be marked access-s2 but to not be triaged as an s2 within its component.

Flags: needinfo?(jteh)

Perhaps we need some keyword to indicate that we don't have plans to ship something in the short-term. That way, these access-s2s can be excluded from searches for user-impacting access-s2s.

You need to log in before you can comment on or make changes to this bug.