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 <[email protected]>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 < > [email protected]> 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 <[email protected]>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 - [email protected] >>> To unsubscribe, change settings or access archives, >>> see http://fluidproject.org/mailman/listinfo/fluid-work >>> >> >> >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
