Open Bug 1232843 Opened 9 years ago Updated 2 years ago

Speak Article in Reader View [iOS]

Categories

(Firefox for iOS :: Browser, defect)

All
iOS 8
defect

Tracking

()

People

(Reporter: dusek, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Some users (including lots of low-vision ones) might like to be able to hear their article in Reader View, optionally with highlighting of currently read text (e.g. by word or sentence). While iOS provides a similar system-wide reading feature on any selected text (Settings.app > General > Accessibility > Speech > Speak Selection), it requires the user to select the whole text of the article first (try it, it sucks so much - you can't "Select All" for starters, and have to fiddle with dragging the fine begin and end selection markers, which is a hassle).

This has been worked on for Firefox for Desktop by the Accessibility team (see "See Also").

This could use AVSpeechSynthesizer. This might also be able to use some code (JavaScript, CSS) from the linked issue in "See Also".
Boris, have you tried how the "Speak screen" feature copes with Firefox for iOS and reader mode? That is different from "Speak selection". You swipe with two fingers from the top of the screen IIRC, and without VoiceOver.
Hi Macro, sorry for the delay.

> Boris, have you tried how the "Speak screen" feature copes with Firefox for
> iOS and reader mode? That is different from "Speak selection". You swipe
> with two fingers from the top of the screen IIRC, and without VoiceOver.

I did not try it before the original report, even though I knew about it. I was probably too excited about possibility of this directly in Firefox for iOS feature when submitting this bug :-)

I tried Speak Screen now and it seems Speak screen does not cope entirely well.

The most serious issue is that it does not scroll the view, more when Speak screen highlights words. This issue is present also in Safari, so I consider it a bug of "Speak Screen" (best to be reported to Apple, best with video). Apple probably can use e.g. `accessibilityScroll` to scroll the content from the "Speak Screen" feature, just like VoiceOver does. There is a workaround for the user - it is possible to freely scroll the article during it being read, so one can keep up with the Speak Screen location (and potential word highlighting) manually.

Second issue is that Speak Screen reads the URL in the address bar before starting reading the article displayed in Reader View. It does not do it in Safari. I guess this is perhaps because Speak Screen reads only so called "speakable content" (e.g. you can verify it by trying Speak Screen on the home screen - it complains that "No speakable content could be found on the screen."), which could perhaps be defined by any text fields, maybe labels, plus any web views. The address bar is a text field, so maybe that is why it is read (and why the 3 Reader View buttons are not read). Perhaps marking the address bar when not activated with a static text or button trait could help to make "Speak Screen" fix it.

Third issue is that the previous and next buttons seem to move by segments of text delimited by links (and non-links). Just like with VoiceOver. I personally think it would feel more natural for a person to move by sentences (or paragraphs). Again an Apple bug.

So to sum it up, first issue is probably an Apple bug, second issue is potentially solvable in our code, third issue is definitely Apple bug. Long-term, it is best to fix all issues (file a rdar, try to fix our code). Also this pre-WWDC time of year is still a very good time to file bugs :-) at least if you expect them to be fixed in the next major release of OS X / iOS. I personally do not think that the situation warrants implementing a short-term solution using our custom code. We would be basically duplicating 95% of the non-trivial effort that Apple put into "Speak Screen" feature, just to fix a few bugs for which there is quite a usable workaround.

So I propose to close this bug after I report the first issue (no auto-scrolling) and third issue (prev/next buttons) to Apple and open a follow-up bug about the second issue (position where Speak Screen starts).
Hi Boris, this sounds like an excellent path forward! Can you post the relevant radar numbers when you have them for reference, and then close this bug WONTFIX?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.