The topTouchArea button in BVC is there to enable users to show the hidden URL bar with a tap. But it seems to get in the way of accessibility in a very hard way - e.g. "Cancel" button is not accessibility (when URL bar is in editing mode), it is visible to VoiceOver cursor even when not needed, etc. Given how useless it is to a VoiceOver (with VoiceOver, the URL bar never gets hidden), it seems most effecient (at least for now) to disable it outright for accessibility.
Created attachment 8626913 [details] [review] Pull Request
Attachment #8626913 - Flags: review?(sarentz)
I was too fast making conclusions about reasons for why "Cancel" button is not available - the reason is actually different than the topTouchArea button. But the other reasons for making the topTouchArea are still valid.
Attachment #8626913 - Flags: review?(sarentz) → review?(bnicholson)
Comment on attachment 8626913 [details] [review] Pull Request Note that the top bar button actually accomplishes two things: it shows the URL bar (as you mentioned), but it also scrolls the page to the top. I'm fine disabling this if you think it's not useful for accessibility, but just wanted to point out that it's not entirely redundant.
Attachment #8626913 - Flags: review?(bnicholson) → review+
(In reply to Brian Nicholson (:bnicholson) from comment #3) > Note that the top bar button actually accomplishes two things: it shows the > URL bar (as you mentioned), but it also scrolls the page to the top. The second one (scrolling to the top) seems to be possible to accomplish by the iOS standard of tapping the status bar (should work for any scroll view). Just tried with VoiceOver and it is the case even for the web view in Firefox. > I'm fine disabling this if you think it's not useful for accessibility, but > just wanted to point out that it's not entirely redundant. Yes, I think we want to disable it at this time, as it definitely does more harm than good.
Since we don't display the status bar in landscape mode, there isn't a way to trigger the scrollToTop action that the scrollView offers. I added a button to display the toolbars if they are scrolled away on landscape and another to trigger the scrollToTop action. I tried to replicate the behavior Safari has. Is there a way we can replicate that while still making it accessible?
(In reply to Stephan Leroux [:sleroux] from comment #5) Thanks for the info, I did not notice these nuances before (nor the Safari behavior). I will try this out later today and comment.
(In reply to Boris Dušek from comment #6) > (In reply to Stephan Leroux [:sleroux] from comment #5) > > I will try this out later today and comment. actually the day after tomorrow - today I am finished and tomorrow will be string-freeze changes for me. :-)
Comment on attachment 8626913 [details] [review] Pull Request Sorry Stephan for the huge delay. I tested with Safari. What it does is that it never hides the top bar in portrait when using VoiceOver. Firefox behaves the same, I guess this is due to the way VoiceOver interacts with the scroll view does not trigger the hiding behavior. In landscape, Safari hides the top bar even with VoiceOver (simply a matter of orientation). Firefox does not hide it just simple because of orientation. So here we are in better standing than Safari based purely on the hiding behavior of top tar being more conservative. Note that it is still possible to trigger hiding behavior with VoiceOver (using a workaround - double-tap and hold, then after sound move finger and it behaves like you were scrolling with one finger without VoiceOver). But I cannot imagine why VoiceOver users would want to do that (except perhaps only VoiceOver geeks just "playing around" and testing the UI to its limits). W.r.t. to scrolling to the top, there is always possibility to confirm any item in iOS status bar at the top. Having an accessible button for that directly in Firefox could be nice, but to tune this to behave as needed in all situations and the button to have the right dimensions and position etc., i.e. to polish it, would certainly require more time that is feasible, given other accessibility features I have in the pipeline, and given the approaching 1.0 freeze. (One more side note on parity Safari vs Firefox: in Firefox, tapping the top does both reveal the top bar and scroll to the top. In Safari, it does only reveal the top bar, which seems to me correct behavior, as revealing top bar and scrolling to top are 2 distinct things which I usually do not want to do at the same time.) So all in all, it seems a button to reveal top bar is not needed for VoiceOver, accessible button for scrolling can be considered as a low-priority feature for the future. I rebased the PR on the latest master and retested. Could you please consider my answer and possibly merge it (before v1.0 :-) ?
Attachment #8626913 - Flags: review+ → review?(sleroux)
Comment on attachment 8626913 [details] [review] Pull Request Hey Boris, Thanks for the analytical investigation on this issue. Looks good - I'll merge this in today :)
Attachment #8626913 - Flags: review?(sleroux) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.