Closed Bug 1212481 Opened 9 years ago Closed 20 days ago

Accessible name of password doorhanger's email entry should be updated to reflect contents

Categories

(Firefox :: Disability Access, defect)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jdiggs, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

The following is the AT-SPI2 accessibility tree associated with the doorhanger prompting the user about remembering the password, where each item is in the form:

   [accessible role | accessible name ] (text: accessible text)

-> [alert | ] (text: None)
    -> [label | /] (text: /)
    -> [label | ] (text: Would you like Nightly to remember this login?)
    -> [push button | Close this message] (text: None)
    -> [section | No username] (text: None)
        -> [entry | No username] (text: my@email.com)
        -> [menu | Would you like Nightly to remember this login?] (text: None)
    -> [section | ] (text: None)
        -> [password text | ] (text: **********)
        -> [menu | Would you like Nightly to remember this login?] (text: None)
    -> [push button | Remember] (text: None)
        -> [menu | Remember] (text: None)
        -> [push button | Remember] (text: None)

Notice this line:

        -> [entry | No username] (text: my@email.com)

Because the accessible name is not being updated, a screen reader speaks something like "No username entry: my@email.com" which is less than ideal.

A couple of possibilities:

1. Change the name / placeholder text to "Username". Then it doesn't need to be updated. (If it is empty, a screen reader could indicate the lack of value by saying nothing or saying "blank".)

2. Update or remove the accessible name when there is a value present so that the name+role+value combination makes more sense when presented.
The "No username" thing is in the placeholder attribute. I expect UX doesn't want to change that because the field should say "no username" when there is no username in it (because then you're saving a password for a site with no username). It needs to be a placeholder because you don't want to store that information with the actual username "no username", not least because for sites that accept usernames with spaces, that could be an actual username (and we definitely don't want to fill it in on a website).

I expect the best solution will be to add an aria-label attribute to both the username and password fields. That will fix the UX for screenreader users without changing it for sighties.

The only other thing I'm wondering is whether the placeholder will still get read after that, both when the textbox is empty (in which case I would kind of want it to get read, though it wouldn't be horrible if it didn't because it'd just say something like "text entry username empty") and when it isn't (when I really don't want it to be read because "text entry username no username myusername" is even more confusing than the current state).
Severity: normal → S3

It seems to be resolved in the current version (Nightly 126) of the password doorhanger - the Username field has a <label> element and, when empty, the placeholder is still there as a placeholder. A11y tree confirms the screen reader output.

Status: NEW → RESOLVED
Closed: 20 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: