Architectural Issues around Text to Speech

Tue Aug 6 16:05:10 UTC 2013

Interesting...

Too bad the demo's not as accessible as it could be... in particular buttons lack proper labels, keyboard shortcuts, nav mechanisms (other than TAB)... but it's simple enough that perhaps these can be added fairly easily.

Cheers,
Jan

(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
OCAD UNIVERSITY

T 416 977 6000 x3957
F 416 977 9844
E jrichards at ocadu.ca

> -----Original Message-----
> From: fluid-work-bounces at fluidproject.org [mailto:fluid-work-
> bounces at fluidproject.org] On Behalf Of Justin Obara
> Sent: August-06-13 11:13 AM
> To: Antranig Basman
> Cc: fluid-work at fluidproject.org
> Subject: Re: Architectural Issues around Text to Speech
> 
> I ran into this on "A List Apart" last night.
> http://www.barneyparker.com/world-simplest-html5-wysisyg-inline-editor/
> 
> Basically it outlines a lightweight HTML wysiwyg inline editor, using
> "contenteditable" and "execCommand". I wonder if we could harness
> "contenteditable" as an easy and/or quick start at implementing the
> functionality designed for the Text to Speech enactor and widget?
> 
> "contenteditable" has fairly wide browser support.
> http://caniuse.com/contenteditable
> 
> Thanks
> Justin
> 
> On 2013-04-29, at 6:53 PM, Antranig Basman
> <Antranig.Basman at colorado.edu> wrote:
> 
> > Hi Justin, Johnny - I believe the approach described here, by the estimable
> Haverbeke, will carry us a long way to a working implementation of arbitrary
> selectable text - as well as lighting the way forward to our general content
> authouring work in some upcoming project. The idea is to constantly
> maintain a hidden textarea node whose contents are "aligned" with the real
> DOM, and use the selection events which are fired by this, whilst just
> cosmetically updating the real DOM. Many more details here:
> >
> > http://marijnhaverbeke.nl/blog/browser-input-reading.html
> >
> > Cheers,
> > Antranig
> >
> > On 19/04/2013 10:45, Johnny Taylor wrote:
> >> Justin,
> >>
> >> "How do we make a selection" with the keyboard alone? That's a great
> >> question. My instinct is Shift > arrow key, but how will it know
> >> where to start? Firefox allows a user to use the cursor key to navigate
> within pages. And using Shift > arrow keys to select content as you use this
> key combo does work to select text.
> >>
> >> That's pretty powerful. Especially in this context. My question given
> >> this is could you mimic this behaviour programatically? To bring this
> >> feature to browsers that don't have this function? And turn it on when
> you enable the text to speech function in UIO?
> >>
> >> Not only would this be nice. I can't imagine another, more intuitive/
> natural, way to do it.
> >>
> >> Johnny
> >>
> >>
> >> On 2013-04-19, at 10:39 AM, Justin Obara <obara.justin at gmail.com
> <mailto:obara.justin at gmail.com>> wrote:
> >>
> >> Yesterday afternoon we started talking and tasking out the work for
> >> implementing the text-to-speech feature in UI options. The notes from
> that meeting are up on the wiki.
> >> http://wiki.fluidproject.org/display/fluid/UI+Options+Text+to+Speech+
> >> Tasking
> >>
> >> In looking through the designs, there are several architectural
> >> issues that have arisen. In the current designs, text-to-speech will
> >> read out the contents of a predesignated section on the page, likely
> >> the contents of the <article>. The user will be able to play and pause the
> reading, but also be able to select a portion of the text via, keyboard or
> mouse, to start reading from. This raises two high level questions.
> >>
> >>  * How do we make a selection?
> >>  * How do we start reading from that selection?
> >>  * How do we know when a selection was made?
> >>
> >>
> >> How do we make a selection?
> >> =======================
> >>
> >> Mouse:
> >>
> >> This is straight forward, and should likely be supported on any system that
> supports a mouse.
> >>
> >>
> >> Touch:
> >>
> >> This is also likely handled by any current OS that supports touch.
> >>
> >>
> >> Keyboard:
> >>
> >> We should be able to make use of the browsers built in caret
> >> navigation. Although this may require the user to enable it in the
> >> browsers settings. Safari and chrome (tested on mac os x) seem to
> behave the same, in that you have to first double click on a word before you
> can use the keyboard to modify the selection.
> >> However, this interaction from Safari and Chrome is not ideal, as the
> >> user would still have to use the mouse to start the selection.
> >>
> >> http://hkitago.com/2009/03/safari-and-caret-browsing/
> >> http://windows.microsoft.com/en-CA/windows7/select-text-and-move-
> arou
> >> nd-a-webpage-with-your-keyboard
> >>
> >>
> >> How do we start reading from a that selection?
> >> ====================================
> >>
> >> This question was particularly nebulous. We would have to know what
> >> was selected, what DOM node that selection was from, and where in that
> DOM node the selection came from.
> >>
> >> Example 1:
> >>
> >> <p> A fool thinks himself to be wise, but*a <strong>wise*
> >> man</strong> knows himself to be a fool.</p>
> >>
> >> In Example 1, suppose we select "*a <strong>wise**". *There are at
> >> least two potential issues 1) starting in the middle of the DOM node, and
> 2) crossing DOM nodes.
> >>
> >>
> >> Example 2:
> >>
> >> <p> Give every man *thy* ear, but few thy voice. <p>
> >>
> >> In Example 2, suppose we selected "*thy*". Since the word "thy" is
> >> contained within the text for the node multiple times, how would we
> know which one was correct?
> >>
> >>
> >> One possible would be to make use of window.getSelection(). This will
> >> provide us with a selection object that we can use to get the text
> >> selected as well as the node(s) that the selection starts and ends
> >> in. We should also be able to determine where in the DOM node the text
> selection is, making it possible to distinguish between multiple occurrences
> of the same text.
> >>
> >> https://developer.mozilla.org/en/docs/DOM/Selection
> >> http://blogs.msdn.com/b/ie/archive/2010/05/11/dom-range.aspx
> >>
> >> There is a question of browser support, particularly for IE 8 and
> >> below, but we might be able to find a polyfil to help with that.
> >>
> >> http://www.quirksmode.org/dom/range_intro.html
> >> http://code.google.com/p/rangy/
> >>
> >>
> >> How do we know when a selection was made?
> >> ====================================
> >>
> >> There doesn't seem to be any specific selection events that we could
> >> listen to. However we could probably use mouse presses, key presses
> and touch events to trigger a check of the selection object (see above).
> >>
> >> http://stackoverflow.com/questions/2859985/event-on-html-selection
> >>
> >>
> >> Thanks
> >> Justin
> >> _______________________________________________________
> >> fluid-work mailing list - fluid-work at fluidproject.org
> >> <mailto:fluid-work at fluidproject.org>
> >> To unsubscribe, change settings or access archives, see
> >> http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> >>
> >
> > _______________________________________________________
> > fluid-work mailing list - fluid-work at fluidproject.org To unsubscribe,
> > change settings or access archives, see
> > http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org To unsubscribe, change
> settings or access archives, see
> http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work