Chromelessness in Engage 0.3 presents an issue for Voiceover use

[Sambhavi Chandrashekar]

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/5b46b4f2/attachment.html>