1068712 - compose screen: improve accessibility of the compose screen.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Marco Zehe (:MarcoZ)]

The touch targets for the screen reader are too small when exploring.

Comment 1

[Yura Zenevich [:yzen] (please use "needinfo")]

There are also several issues with recipients fields, header roles, etc.

Comment 2

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: Github pull request.

Comment 3

[James Burke [:jrburke]]

Comment on attachment 8548654 [details] [review]
Github pull request.

Talked in IRC and have some notes in the pull request. The line break issue for long addresses is probably the biggest thing to sort out. Feel free to contact me in IRC if need more discussion, otherwise, just flip the review back to me when you want me to do another pass.

Really great to see these changes, thanks for the pull request!

Comment 4

[Yura Zenevich [:yzen] (please use "needinfo")]

Comment on attachment 8548654 [details] [review]
Github pull request.

(In reply to James Burke [:jrburke] from comment #3)
> Comment on attachment 8548654 [details] [review]
> Github pull request.
> 
> Talked in IRC and have some notes in the pull request. The line break issue
> for long addresses is probably the biggest thing to sort out. Feel free to
> contact me in IRC if need more discussion, otherwise, just flip the review
> back to me when you want me to do another pass.

Addressed all the comments in Github. I had to keep the flex layout for address and peep-bubbles as I could not figure out how to reliably maximize the input text field to the space available for it on the same line with contacts. Hopefully it cleans up things a bit, instead of complicating them :)

> 
> Really great to see these changes, thanks for the pull request!

Comment 5

[James Burke [:jrburke]]

Status on the review: I have gone through it and it all looks good except for with the flex layout for the bubbles and input, I am occasionally seeing an issue with using + to add a contact bubble. Sometimes the in put moves to a new line even though there is enough space to keep it on the same line as the bubble.

If I remove remove flex-grow: 1 from the input.cmp-addr-text, then it does not have the problem, but the issue of not breaking to new line when there is not enough space on current line (one of the feedback items) occurs. So that is not the answer.

Could be a browser quirk or bug where, depending on something I have not identified yet, the input is not sized down smaller to fit on the line, and is instead the full 231 px wide (plus 5px margin-left), which then, according to the styles, means it should be on a new line since it is the full width of the container.

When it acts as expected, and I measure the box size of the input, it is 159 instead of 231, so no new line break. Seems like perhaps depending on when the browser decides to measure the children determines if the input is full size or a reduced size.

So I am trying to see if that side effect can be avoided. I do not want to end up with a bug report for that side effect at some point. When the extra line quirk does happen, it takes up more vertical space, and I think it is an extra space or something, so I press backspace on the keyboard, but that just deletes the previously inserted contact bubble. Which gets slightly annoying.

Comment 6

[James Burke [:jrburke]]

:yzen, if I take the changes you have in this pull request and just revert the changes to compose_cards.css, so back to the float stuff, I seem to be able to navigate to the text boxes using the screen reader.

In general, navigating around fxos, navigating with the screen reader seems tricky, and works best if I do my swipes and double-taps at the very top of the screen over the unmoving status bar. Using that approach, I seem to be able to select the text inputs and a contact bubble I insert.

Is that the screen reader issue that was being addressed with the compose_cards.css change, or something else?

My next thought to get the flexbox to work was to introduce more container divs, but did not want to introduce more HTML if I could avoid it, and if I do, want to make sure I am fixing the correct issue.

Comment 7

[Yura Zenevich [:yzen] (please use "needinfo")]

Hi James,

Thanks for looking into it in such detail! 

So regarding Comment 5 I can still play around with some of the flex settings, it looks like what happens is the browser is trying to give flex's children relatively similar widths and that results in the overflow and the input jumps to the next line. It's just a speculation but I'll investigate more.

Regarding Comment 6, I think you might find this link helpful (perhaps in the future too), it describes ways of interacting with the screen reader: https://wiki.mozilla.org/Accessibility/Mobile/ScreenReader . Mind you, about half of the stock apps are not accessible yet, so you might get stuck occasionally. 

In terms of the actual a11y issue, the problem lies in the fact that the input field is a very tiny target by default. The user expects that tapping anywhere in the to: section, for example, will result in the keyboard popping up. That is done programmatically via the event handler for click, afaik. 

This, however, does not work pefectly with the screen reader because it actually needs to find a target first to activate it. Which means it needs to be focused on the input field first. 

What you described (successful activation) happens because you can get to the input field sequentially. That's a fairly slow mode of operating the screen reader since the app's markup can be quite big and complicated. Another way of navigating is called Explore By Touch where you hold the finger on the screen and explore things (announced by the screen reader) without lifting it. But for that the target needs to be substantially bigger.

So, from what I understand, the ideal solution for this issue is for the input field to take up all available space in the section limited only by possible contact bubbles. If it needs to jump to the next line because it grows too long, it should again take up the whole line unless new bubbles show up on that line. That's pretty much why flex felt like a good fit, imo, except for the issue that you describe in Comment 5.

Comment 8

[Yura Zenevich [:yzen] (please use "needinfo")]

I think it is working now. Let me know if it looks good to you!

Comment 9

[James Burke [:jrburke]]

Comment on attachment 8548654 [details] [review]
Github pull request.

Great, the flex-shrink seems to fix the issue, thank you for your persistence in getting it to the finish line! I really appreciate the guidance on the screen reader behavior too.

Comment 10

[Yura Zenevich [:yzen] (please use "needinfo")]

https://github.com/mozilla-b2g/gaia/commit/57732380a6d2ac2ac704b37ac2ee9d2b485d03c4

Comment 11

[Yura Zenevich [:yzen] (please use "needinfo")]

Comment on attachment 8548654 [details] [review]
Github pull request.

[Approval Request Comment] This patch makes compose screen accessible to screen reader users.
[Bug caused by] (feature/regressing bug #): Improvement
[User impact] if declined: Screen reader users will have an inaccessible compose screen in the Email app.
[Testing completed]: Added unit tests for the changes
[Risk to taking this patch] (and alternatives if risky): Some CSS changes that went through several rounds of review so hopefully medium to low.
[String changes made]: https://github.com/mozilla-b2g/gaia/pull/27364/files#diff-4

Comment 12

[bhavana bajaj [:bajaj]]

Yura, can we get some on-device testing as well before uplifting the patch?

Comment 13

[Yura Zenevich [:yzen] (please use "needinfo")]

I did all my development/testing for this bug on device, does that suffice?

Comment 14

[bhavana bajaj [:bajaj]]

(In reply to Yura Zenevich [:yzen] from comment #13)
> I did all my development/testing for this bug on device, does that suffice?

yep, thanks! and thanks for adding the unit tests.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/7194ade6ccf3583dc785cc2f6181c0809b43983f