I am blind and use voice-over for navigation.

Majority of the app works very well with voice-over, however, some text is not spoken. What I have noticed is that it is usually the comments that are not spoken.

This is a real shame, because this one little defect renders this app useless for a blind or visually impaired person.

I would be grateful if you could give it your utmost attention and resolve this issue.

  • App Version: 1.4.0
  • Device: iPhone6,2
  • OS Version: Version 9.0.1 (Build 13A404)

A new beta version is out. I will be emailing you instructions for downloading it.

What's fixed:

  • Comments are now accessible.
  • Scores are described more clearly in their own element preceding the content, e.g. "Accepted answer with 4 votes." or "Comment with 2 upvotes".
  • Question tags and duplicate question information now work.
  • All interface elements are at least accessible by tapping into them.

What's still terrible:

  • Three finger scrolling does not work when a post body element is active.
  • When swiping right into an answer body from the score information or from a post body into the action toolbar, the app may scroll to the top. I thought I had fixed this but now I can't get it to work.
  • Comments provide each link first, then the comment body, so a comment that looks like: "Text link text link text" will read "link url; link url; Text link text link text".
  • Comment links are not correctly oriented over their content.

Technical description of changes:

The biggest change revolved around the comment labels, which use TTTAttributedLabel to render text and links. TTTAttributedLabel introduced accessibility in version 1.10 but it was broken and continues to have some issues. The flaw that they fixed is that the calculated screen relative accessibility frames once and did not account for scrolling. This has been fixed in an unreleased version. The other issue I was having is that because TTTAttributedLabel is a subclass of UILabel it gets special accessibility treatment inside a UITableViewCell. To solve this, it needs to be a child accessibility element of a parent accessibility element and not searched via the view hierarchy. Other issues, as mentioned above are the way they read the text and position the child accessibility frames.

Most other issues encountered revolved around structuring things for accessibility how UIKit finds accessibility elements. It searches the view hierarchy until it finds a view with isAccessibilityElement == YES or accessibilityElementCount != 0. If a view is an accessibility element, its child views and child elements are ignored and all that matters are its frame, label, hint, etc. Otherwise, if accessibilityElementCount is non-zero, the child views are ignored and accessibility just navigates the views. In that case, it is critical that all elements returned by that view are an element or have accessibility children. For example, I ran into issues when I tried having a web view be an accessibility child because not it but one of its subviews is the accessibility container, so the whole thing was invisible to VoiceOver.

Next steps:

  • Some more in depth research around web views and accessibility.
  • Extending TTTAttributedLabel to improve accessibility support.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .