Chromelessness in Engage 0.3 presents an issue for Voiceover use

[Sambhavi Chandrashekar]

Please read the subject as "The current chromeless version of Engage 0.3
presents an issue for Voiceover use" :))

On Wed, Feb 3, 2010 at 2:48 PM, Sambhavi Chandrashekar
<sambhavic at gmail.com>wrote:

> I started using Engage on iPhone through Safari to overcome the navigation
> problem. I have described below an  observation I made comparing this with
> the chromeless version, which might present a significant usability issue
> for Voiceover users:
>
> On Safari, upon a successful page transition in Engage, Voiceover
> automatically announces 'Web page loaded' and speaks out the title of the
> new page (which is vital for Voiceover users to know whether (a) their
> action was successful (b) page load is complete and (c) the desired page has
> loaded (assuming page titles are given appropriately). On the chromeless
> version, there is no feedback through Voiceover that a new page has loaded
> although visually I can see the new page. More interestingly, I am required
> to tap on the screen to bring Voiceover focus to the new page. If, without
> tapping, I just flick one finger down to read element by element or two
> fingers down to read continuously, Voiceover reads the previous page. If I
> were not visually looking at the new page, I would have been led to believe
> that my action to load a new page has not succeeded.
>
> The fact that Voiceover does automatically announce new Engage pages on
> Safari might provide clues to those who know how to address this issue (I
> don't ;))
>
> Thanks.
>
> Sam
>
> On Wed, Feb 3, 2010 at 1:29 PM, Sambhavi Chandrashekar <
> sambhavic at gmail.com> wrote:
>
>> Hi Colin,
>>
>> Thank you for your reply last evening. My main question was indeed about
>> the chromelessness in Engage and how I was getting caught without being able
>> to go back. I was starting new sessions of FE on the iPhone every time and
>> wasn't sure if the earlier sessions actually ended or were still running
>> somewhere and draining the battery. I was hesitant to spam the list about it
>> because things are still under development. I did write about some other
>> issues to the list.
>>
>> Thanks.
>>
>> Sam
>>
>>
>> On Wed, Feb 3, 2010 at 11:20 AM, Colin Clark <colinbdclark at gmail.com>wrote:
>>
>>> Just as a follow up to this thread, I did indeed commit this fix to trunk
>>> a few days ago, and it's working nicely and chromelessly on the daily build
>>> instance of Engage 0.3.
>>>
>>> There's one caveat: we haven't yet implemented our own custom navigation
>>> bar and back button, so the only direction is forward for the next few days.
>>>
>>> Colin
>>>
>>> On 2010-02-01, at 4:30 PM, Colin Clark wrote:
>>>
>>> > Hi Justin,
>>> >
>>> > Wow, you're on to something here! Nice detective work!
>>> >
>>> > On 2010-01-31, at 7:58 PM, Justin Obara wrote:
>>> >>
>>> http://www.coldfusionjedi.com/index.cfm/2008/10/9/Two-iPhone-development-tips-and-jQuery-to-the-rescue
>>> >>
>>> >> The site mentioned above, talks a bit about these issues, but if you
>>> read on down into the comments, there may be some hacks to work around the
>>> problem for navigating between pages. Seems like some people have had
>>> success keeping the full screen webapp alive outside of safari if you use
>>> the link to have javascript change the window.location.href to the desired
>>> url.
>>> >
>>> > The comment on this blog does indeed mention how assigning to
>>> window.location won't cause Safari's chrome to appear. I tossed the
>>> following more unobtrusive code into the Home screen, and it worked!
>>> >
>>> > jQuery("a:not([href^=#])").click(function (evt) {
>>> >    window.location=$(this).attr("href");
>>> >    evt.preventDefault();
>>> > });
>>> >
>>> > There are a couple of consequences to this. For starters, we're
>>> assuming that all links that start with # aren't going to cause a page
>>> transition. This is probably sensible, but not necessarily safe. I think
>>> it's reasonable for Engage 0.3, however.
>>> >
>>> > The only case this won't address is page transitions that occur as the
>>> result of a form submission. For now, we'll probably be fine. Perhaps the
>>> Jedi is correct and this won't be a problem anyway.
>>> >
>>> > We'll probably need to put this code into a JavaScript file that all
>>> our components use. Off the top of my head, it seems reasonable to bind it
>>> as a live() event so that it will work with all links, regardless of
>>> Renderer usage, etc.
>>> >
>>> > Thoughts, comments, or reasons why we shouldn't go ahead and do this
>>> for Engage 0.3?
>>>
>>> ---
>>> Colin Clark
>>> Technical Lead, Fluid Project
>>> http://fluidproject.org
>>>
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at fluidproject.org
>>> To unsubscribe, change settings or access archives,
>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20100203/827acb4b/attachment.html>