Agree in principle. However I think there's some design complications here, in that the TOC is scrollable, and scroll under the status bar.

Because there's no quick win option, I am lowering the priority of this to normal and moving it forward for our designers to work on.

In T124820#1967680, @JMinor wrote:

Agree in principle. However I think there's some design complications here, in that the TOC is scrollable, and scroll under the status bar.

I see, you are right. Thinking about this more:

– For blind VoiceOver users, the scrolling issue is irrelevant as that is a visual matter. These users do not even know about the scrolling when they navigate by swiping (which is the only reasonable way to navigate the TOC I think).
– Motor handicapped Switch Control users, on the other hand, scroll manually, so if we placed the Close button next to the "CONTENTS" label, they would sometimes get into situations where the Close button is on another screen and therefore not selectable. However, it would be selectable on the first screen and that would already solve the situation when the user opens the TOC by mistake. Also, it is only possible to go to the subsequent screens by first visiting the first screen (including the "CONTENTS" label and the possible close button). Therefore, the users would at least know that the Close button is there, although they have to scroll back to find it.

The same as for Switch Control users can be said about healthy users, for whom it also must be considered that scrolling is easy for them.

Therefore it seems to me that having an always visible Close button would be best, but having a Close button next to the "CONTENTS" label (and subject to scrolling) is still far better than having no Close button at all. In other words, if implementing an always visible Close button would seem to be to difficult to accomplish soon, the Close button next to the "CONTENTS" would at least solve the main accessibility issue for now (not being able to get out of the TOC).

@Nirzar @JMinor friendly reminder, this needs some TLC from design so we can ship the app ;-)

@BGerstle-WMF @Nirzar has a design completed, and will merge/attach to these tickets.

I merged this already, but just discovered it doesn't work in RTL:

Just to be sure, I checked the view hierarchy in visual debugger and sure enough close button is still in top left:

Moving back to "blocked" so one of us can add RTL compliance for this button

There is still no explicit button to dismiss the Table of Contents so the requirement for VoiceOver and Switch Control has not been addressed. However as noted a regular iOS user can dismiss it by tapping outside the table or on one of the contents.

Testing on iOS 9 iPad using the latest build (760), there is now an X on the left of the Table of Contents that is a Close button. So this looks fixed.

This is only partly fixed in that it now gives a clear indication to seeing people how to dismiss the TOC. But for some reason, the button is still not accessible with VoiceOver (I didn't test with Switch Control yet).

I had a quick look at it but it wasn't immediately obvious to me why this is so. The button is not affected by the presenting view controller hiding logic that we implemented to make the TOC behave modally in assistive technologies. I have also noticed that one is not supposed to add subviews directly to a UIVisualEffectView (see docs), but that is not the main problem either. I did not investigate it further.

I think we will also eventually want to fine-tune the accessibilityLabel and accessibilityHint. The shorter text should go to the label, which is the text that is always spoken, the hint is a an optional subsequent "help" message that is spoken when the user hesitates on an element.

This is also not immediately obvious to me. I need to do further investigation - or we need some help from an accessibility consultant. Either way this is probably going to be a longer task.

Lets scope this fix to making VoiceControl recognize and provide appropriate hint for close button.

The app actually already has a hint and a label for the close button…

Looking for more low hanging fruit before punting

So - it looks like the standard escape gesture was working. (Draw a "Z" with 2 fingers)

Not sure why this was kicked back.

As an extra I added support for a magic tap, with is a simpler gesture (Double tap with 2 fingers)

Either way, it works now.

See "Responding to Special VoiceOver Gestures" here for more info:
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/SupportingAccessibility.html

To be clear - the close button is still unreadable by voiceover.

However, it is unneeded. Just like the text size popover, the ToC can be dismissed using the standard voiceover escape gesture.

I think this is sufficient for this original ticket. If additional improvements are needed lets work them on new tickets.

@Fjalapeno @JMinor, I fear that PR#672 is a wrong solution. There are several aspects to this:

– Magic Tap is not supposed to be used for escaping views and users are definitely not expecting it. Even users who would need it won’t be able to make any use of it in this situation anyway because they have no way to know that it is available here and what it does. If ever users invoke it, they will have been expecting something entirely different out of it.

– We are aware in this ticket that the escape (“Z-shaped”) gesture is already implemented in this situation, see the original description of the ticket above. My colleague @dusek has implemented that before this issue was created. However, the original description of this issue also briefly reasons why this should not be the only way to close the dialog.

These special gestures like Magic tap and escape are meant as shortcuts to perform actions quickly for more advanced users, but should not be the only way possible to access something important, I think Apple talks about this on one of their accessibility WWDC videos, but this is also obvious from practical experience with training blind people with VoiceOver. The basic VoiceOver navigation really is swiping left and right, touching things and confirming with double-tap. The user should be able to get by with that for basic navigation. It still is *much* harder than for a seeing user.

Also, some users aren’t able to do these more complicated gestures like the Z-shaped gesture with two fingers due to problems in hand coordination, motor problems with their hands etc. Misperforming this rather complicated gesture and invoking some other (unwanted) gesture in the process is also a real problem for many less skilled VoiceOver users even without any other additional issues, this usually results in the user getting disorientated and “lost”. Imagine what would happen if we asked the “normal” seeing users to always close the TOC in this way :-)

I see very well how you could have expected that this is the way to make it accessible, but be aware that Apple’s documentation on accessibility is unfortunately very sketchy and not nearly going into enough practical details. It is often necessary to test things against other sources and against practical experience.

– VoiceOver is also intended for users who still have sight, but they see badly. Switch Control users mostly won’t have any problems with vision at all, they just have a problem with input. These are groups of users who will see the provided close button with their eyes and they won’t be able to interact with it, which is frustrating for the users and obviously wrong. So we need to make the visual button accessible in any case.

– Using MagicTap here for this very specific scenario interferes with the idea of possibly using MagicTap to solve https://phabricator.wikimedia.org/T126922 . While the possible use of Magic Tap there is still something to be carefully considered, I think we do not want to remove from ourselves the possibility of using it in the future for other meaningful things (the issue also discusses another possible use of Magic Tap).

I appreciate very much that you are trying to fix this and thinking about these users, but I think it would be best to revert PR#672 . While this might not be the most pressing accessibility issue right now (there are some more serious accessibility issues), I still think the right way to solve this in a way accessible to everyone is to make the Close button accessible. It appears to me that the problem why it is not reachable now is that it is being added into a sibling view of a modal view and AT then judges that therefore it should not be accessible, but I think it needs some more detailed examination to really judge how to best fix it.

Testing on iPhone with iOS 9.3.1 on the Wikipedia 5.0.3 (838) app. The Z shape and Magic Touch are implemented and working. However, see the above comment from hhanke.

Also noted during our audit of 5.0.5:
"The table of contents does not have a back button. The scrub gesture to go back does work however."

The close button is now accessible… this was due to a bug that as resolved in iOS 10