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

This looks great, thank you! This will really help many people!

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).

@JMinor OK, understood. Thank you again for thinking about these people!

@JMinor Due to other work, I won't be able to look at it before the weekend, but maybe I could send something on Sunday if that would still be useful to you. This said, I would also be concerned about the possibility that such a last-minute modification at a key place might break something (although in theory it should only affect Switch Control). Do you still plan to do some significant testing after Sunday?

@Fjalapeno I would say that reloading the web view would likely result in loosing the VoiceOver focus (so the user would land at the beginning) which is what we can already achieve by sending the screenChanged notification but we would prefer if the cursor remained where it was before the gesture so that the user could continue reading seamlessly. But I will try it, just in case :-)

• Thanks for the suggestion with role=presentation, that would be an excellent solution! I did not try it before so I tried it now, but unfortunately it turns out VoiceOver ignores it completely on <a>elements. W3C says this role should not be used on visible focusable elements, so I tried to add tabindex=-1 but no joy. I think VoiceOver simply doesn't go that far. But you are right, that would be the simplest solution if it could be used.

@TheDJ Interesting, apparently for some blind people it is even enough reason to look for a third-party reader that would not do links at all.

@TheDJ Yes, thank you for the suggestions, it is very useful to consider them, but I think there are significant drawbacks in using just Dynamic Type for the size of articles:

@BGerstle-WMF Investigating this issue more and giving it some more thought, I think we should observe the status of Switch Control in WMFArticleViewController or in a similar place. When Switch Control is running, we could set a preferOnclickEvents variable in javascript and then we can react to it when handling events. If preferOnclickEvents is true, we would maintain the preventDefault() behavior in document.onclick() but simulate a touchended event by calling touchEndedWithoutDragging() directly. I tested this and it seems to solve the original problem.

@BGerstle-WMF @MBinder_WMF @JMinor I Believe I have now added tickets for all the most important issues from our report, the ones that I consider being the most significant barriers to disabled people using the iOS app. Please feel free to sort and tag them as necessary.

This is also related to T126689.

@MBinder_WMF Maybe we should also remove "in VoiceOver mode" from the title since we are also tracking other accessibility issues here?

@BGerstle-WMF If you want to try it, I recommend to set Settings->General->Accessibility->Accessibility Shortcut to Switch Control (and only that). This will make it easy for you to turn it on and off using three quick presses of the home button.

The problem of hyperlink activation with Switch Control seems to be in the handling of events in the javascript listeners.js, which disables the standard onclick event in favor of custom handling of users touches in handleTouchEnded(). I have verified that taping a hyperlink inside the web view with Switch Control does reliably fire an onclick event on the link, but it doesn't fire the touchend event. Therefore, the onclick event is dismissed and nothing happens.

@Fjalapeno Since I don't know how and to which purpose exactly do you use priorities in this project, I might very well be mistaken. But it still seems to me that since this bug renders a core functionality unusable by a certain class of users, it seems strange to me that it should be classified as "Low".

So we got a reply from Chris Fleizach from Apple and basically he says that the javascript approach is right. He also says the the UIAccessibilityScreenChangedNotification(nil) behavior, the one that is causing us troubles, is intended. However, he thinks that the UIAccessibilityScreenChangedNotification(UIWebView) could in the future respect the position of the web view internal focus. That would likely be a solution for our problem here.

@BGerstle-WMF I have just reported two issues relating to Switch Control rather than VoiceOver. Being aware of this but not being able to decide whether you would prefer to create another "umbrella" issue for accessibility problems with Switch Control or whether you would prefer to rename this task, I have opened these as subtasks of this issue for now so that all the people interested in accessibility work get notified.

This proves to be a tricky issue. I have attempted at solving this in two steps:

The current experience for a VoiceOver user is as follows:

I believe this is now resolved.

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 believe this is fixed in PR 414

Another two situations where this is needed is ShareOptions and References.

The related issue I mean to mention is T124593 .

@JMinor This bug does not try to solve how to escape from modal views, just that the views behave modally towards assistive technologies. I will be submitting a patch for this.