Bug: Improve semantics and accessibility of the addressbook view/edit side panel
Status: RESOLVED
Priority: P1
Resolution: FIXED
Created: 2021-06-22 14:24:48+00:00
Resolved: 2022-08-24 09:09:13+00:00

I like the look of the new address book. Its also a good opportunity to improve the semantics and improve accessibility.

Here are some thing I noticed:

+ ~~I'm not sure if the `sortContext` and `bookContext` popups are accessible. Someone with a screen reader could test them. In the accessibility tree, the menus appear at the end of the document, rather than in place, but I'm not sure if a screen reader is able to handle this.~~
+ The `bookContext` context menu does not appear when the address book has focus and the user pressed the Menu Key on their keyboard. Maybe use the `contextmenu` event instead https://developer.mozilla.org/en-US/docs/Web/API/Element/contextmenu_event. (moved to bug 1753286)

When editing a contact:

+ The `id="photo"` element is a `<div>` rather than an `<img>`. Which means in the accessibility tree it appears as an empty `section`. I don't think we should hide the photo section for screen-reader users, in which case it needs a generic but useful `alt`: something like `"No photo for <contact>"` and `"Photo for <contact>"`, as appropriate. The same goes for the when the contact isn't being edited.
+ The photo can only be set through drag and drop. I'm not sure if another mechanism is already planned. But some way to select an image using clicks only and keyboard only should be supported.
+ The `<label>` and `<input>` pairs use both `for` and `aria-labelledby`. The former is sufficient, so there is no need for `aria-labelledby` (https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation). `aria-labelledby` is only meant for if such a `<label>` is missing.
+ The "First" and "Last" field names are not that clear. "First Name" and "Last Name" would be clearer.
+ The two "Phonetic" fields appear visually beneath the corresponding "First" and "Last" fields, but in the document structure, and in the accessibility tree, they are ordered as `First, Last, Phonetic, Phonetic`, so it isn't clear what the "Phonetic" fields refer to. The order should be changed in the document so that the First Name "Phonetic" appears immediately after "First Name". The CSS `grid-column-start` can be used to keep the display the same as it is now. To be extra clear, the titles `"First Name Phonetic"` and `"Second Name Phonetic"` could be used so there aren't two fields with the same label.
+ The grouped fields could be put in `<section>`s, with the current `<h2>` headers at their start. This would help split up the fields. I think that the headers would already allow screen-reader users to skip to the next section (e.g. skip "Work Address" without going through each field), but I'm not sure. But I think this would improve the semantics regardless.
+ The second `<input>` of the "Address" fields has no associated `<label>` or accessible name. Either we could use two visible `<label>`s with "Address Line 1" and "Address Line 2" text. Or if we want them to be invisible, you can set the `aria-label` attributes to `"Address Line 1"` and `"Address Line 2"` (see the previous link for the accessible name calculation, and https://www.w3.org/TR/wai-aria-1.1/#aria-label).
+ There is no "Cancel" or "Save" `<button>` at the bottom. If the user was tabbing through the fields, then they would have to backtrack from the end to the start. Either the buttons can be moved to the end, or duplicated at the end.

There's likely some more, but these are the ones that I noticed looking at the document and the accessibility tree alone. Also, let me know if I've got any of the aria information wrong.