Maintaining/announcing user focus [was Lightbox Component and IE 6 & 7 Compatibility]
Richard Schwerdtfeger
schwer at us.ibm.com
Mon Jul 2 21:35:39 UTC 2007
Hi Mike,
In the case of 2:
If you want to move back to the last location, you should save the id of
the element that last have focus and set it back when you exit the menu.
Whether you escape from the menu or select an item you have the option of
moving focus back to the menu. If you have a number of objects reusing the
a context menu you could store this id in one place in your document. Also,
you need to decide if your menu will selection will take the user to
another focus location rather than the place which launched the menu ...
but:
oldfocus = document.getElementById(id);
oldfocus.focusI();
In the case of 3.;
If you are reloading an entire page:
You can cache the id of the last element that should receive focus on a
server using AJAX. When you reload the page your onload handler could
communicate with the server get the id and set the focus accordingly. AJAX
is simply a vehicle to communicate with the server, in the background,
without loading the page. The xml data passed back has no real format to it
so how you process it is up to you and the server.
If you are modifying parts of the page:
In this scenario, you are using AJAX to get information from a remote
server to update parts of the page vs. reloading the entire page. The
information us used to update parts of the page using document writes.
Today, JAWS runs in process with your browser (this was not always true in
the past). It is notified of document change events either through MSAA
events or DOM change events. It can then update it view of your page in
process. As long as the focus does not change you should be find. How JAWS
responds depends on where the user is on the page and the context of that
location.
If I am stating things you already know I apologize in advance. ... Just
trying to answer the questions.
Cheers,
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer
Michael S Elledge
<elledge at msu.edu>
To
07/02/2007 02:26 Richard
PM Schwerdtfeger/Austin/IBM at IBMUS
cc
fluid-work at fluidproject.org,
fluid-work-bounces at fluidproject.org
Subject
Re: Maintaining/announcing user
focus [was Lightbox Component and
IE 6 & 7 Compatibility]
Hi Rich--
Thanks! My question has to do with situations two and three:
2. "Focus only moves if the user moves focus. If the focus moves such as
you pop up a menu, move focus to it, and wish it to move back you will
need to keep track of where the focus was before the menu was popped up.
In Dojo, I believe there is page focus management built in to handle
this situation."
What's the best way to keep track of the focus so the user will be
returned to the original location?
3. "If you reload a page you have a "new document" and focus starts at
wherever the page designates."
For this instance, I'm wondering how JS/AJAX tells the browser to put
focus on a particular part of the page, to avoid refreshing at the top
of the page. My other question is if the screen reader will say
something by default to the user when the page changes, or if that is
accomplished by putting text in a tag, such as "Occupation input text
entered, list of specializations follows."
Mike
Richard Schwerdtfeger wrote:
>
> Hi Michael,
>
> If I didn't understand your question please let me know. ... I think
> this addresses you are asking:
>
> If you make incremental changes to the page (small DOM udpates) the
> focus does not move any more than a typical tabindex.
>
> Focus only moves if the user moves focus. If the focus moves such as
> you pop up a menu, move focus to it, and wish it to move back you will
> need to keep track of where the focus was before the menu was popped
> up. I Dojo, I believe there is page focus management built in to
> handle this situation.
>
> If you reload a page you have a "new document" and focus starts at
> wherever the page designates.
>
> If you want a page reload to maintain a point of regard you might
> consider using AJAX to stash this information on the server for later
> retrieval at onload time.
>
> Rich
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> Chair, IBM Accessibility Architecture Review Board
> blog: http://www.ibm.com/developerworks/blogs/page/schwer
> Inactive hide details for Michael S Elledge <elledge at msu.edu>Michael S
> Elledge <elledge at msu.edu>
>
>
> *Michael S Elledge <elledge at msu.edu>*
>
> 07/02/2007 12:14 PM
>
>
>
> To
>
> Richard Schwerdtfeger/Austin/IBM at IBMUS
>
> cc
>
> fluid-work-bounces at fluidproject.org, fluid-work at fluidproject.org
>
> Subject
>
> Re: Lightbox Component and IE 6 & 7 Compatibility
>
>
>
>
> Hi Rich--
>
> Does tabindex= -1 return the focus to its starting point? For example,
> if focus is on a text field, is it possible for the focus to return
> there after a return trip to the server or DOM has added new content? Or
> is that better accomplished some other way?
>
> Mike
>
> Richard Schwerdtfeger wrote:
> >
> > Hi Johnathan,
> >
> > 1. That is not true. You need to set the tabindex=-1 or 0 depending on
> > your application. You don't want to use anchors as this places things
> > on the taborder.
> >
> > See http://www.w3.org/wai/pf/roadmap for the tabindex definitons.
> >
> > The Dojo toolkit is using tabindex extensively as described above.
> >
> > So when you set tabindex="-1" you can use JavaScript to set the focus
> > on the element and it will not appear in the tab order. If you set it
> > to "0" it will appear in the taborder in the document order it resides.
> >
> > This works in IE 6, 7, FF >= 1.5, and Opera 9.
> >
> > Rich
> >
> >
> >
> >
> > Rich Schwerdtfeger
> > Distinguished Engineer, SWG Accessibility Architect/Strategist
> > Chair, IBM Accessibility Architecture Review Board
> > blog: http://www.ibm.com/developerworks/blogs/page/schwer
> > Inactive hide details for "Jonathan Hung"
> > <jonathan.hung at utoronto.ca>"Jonathan Hung" <jonathan.hung at utoronto.ca>
> >
> >
> > *"Jonathan Hung" <jonathan.hung at utoronto.ca>*
> > Sent by: fluid-work-bounces at fluidproject.org
> >
> > 06/20/2007 12:57 PM
> >
> >
> >
> > To
> >
> > fluid-work at fluidproject.org
> >
> > cc
> >
> >
> > Subject
> >
> > Re: Lightbox Component and IE 6 & 7 Compatibility
> >
> >
> >
> >
> > Hello everyone,
> >
> > We've continued our investigation into IE compatibility with the
> > Lightbox component focusing on some of the problem areas we
> > experienced earlier:
> >
> > 1. DIV focus doesn't work on IE
> > 2. JSUnit 2.2a may not be compatible with Dojo
> >
> > *
> > #1 Div Focus:*
> >
> > IE 6 & 7 follows the DOM 1.0 and 2.0 spec in that it will not focus
> > any element that is not a form element (checkbox, radio button etc.)
> > or an anchor. With this in mind, we changed the Lightbox Javascript to
> > put focus on the anchor inside the first thumbnail by using tabindex.
> > This required dynamically changing the tabindex each time the user
> > moved around the Lightbox so that onblur returning to the Lightbox
> > would maintain what was last selected.
> >
> > However dynamically changing the tabindex via Javascript would create
> > unexpected tabbing orders if the user first focuses on another
> > component on the UI. Also Firefox created some strange behaviour by
> > not styling components properly after we modified tab index.
> >
> > All of this experimentation stems from the fact that IE does not allow
> > focusing of DIVs (as per DOM spec). In a quick experiment, we tried
> > the MochiKit Javascript Toolkit and it appears that MochiKit's event
> > handling captures DIV focus event, even if the Browser does not. So
> > it's a possibility that we can use MochiKit instead.
> >
> > We will continue investigating Dojo's event handling to see if it is
> > capable of capturing DIV focus events in a browser independent manner.
> > */
> > !! None of this code has been committed to SVN since it was all
> > experimental and the tests did not pass.
> >
> > /*
> > *
> > #2 JSUnit 2.2a may not be compatible with Dojo*
> >
> > JSUnit 2.2a now works with Dojo in IE. This is no longer an issue.
> >
> >
> > Feel free to post questions/comments to this thread!
> >
> > - Jonathan.
> >
> >
> > On 13/06/07, *Jonathan Hung* <_jonathan.hung at utoronto.ca_
> > <mailto:jonathan.hung at utoronto.ca>> wrote:
> >
> > During some recent testing, we have discovered that the Lightbox
> > component is not completely functional in Internet Explorer.
> > From a User Experience perspective the component is buggy in IE,
> > though in certain circumstances it /can /work the way we expect,
> >
> > The following are the issues we've encountered in the past week:
> > *
> > 1. DIV focus*
> > Currently in Firefox 2+, when you tab to the Lightbox component
> > the first thumbnail would become selected to indicate that the
> > user can perform actions on the thumbnails. However in IE 6 & 7
> > focusing on that DIV is inconsistent and therefore causing the
> > resulting arrow and CTRL key actions to not work.
> >
> > If you're interested in more detail and how to get the component
> > to work in IE before we get a fix in place, please let me know.
> > This is a UX problem in IE and we are currently investigating
> > solutions.
> > *
> > 2. JSUnit tests do not run in IE 6 & 7 if Javascript test code
> > is located in a seperate file.*
> > Currently the Lightbox unit test is separated into two files:
> > LightboxTests.html and LightboxTests.js. With all the test
> > Javascript code in the LightboxTests.js file, JSUnit will not
> > execute the tests in Internet Explorer 6 & 7.
> >
> > One way to overcome this is to copy the contents of
> > LightboxTests.js into LightboxTests.html. There may be another
> > solution, but more research is required. Ideally we would like
> > to have our test Javascripts residing in a separate file for
> > maintainability and separation of function.
> > *
> > 3. JSUnit 2.2a may be incompatible with Dojo*
> > During our testing, we discovered that JSUnit 2.2 Alpha (latest
> > downloadable release) is not compatible with IE 7. Attempting to
> > run the tests will yield "dijit is undefined" or "fluid is
> > undefined" errors. JSUnit 2.1 (the last stable release) appears
> > to work as expected with IE7. A solution would be to use version
> > JSUnit 2.1 instead of JSUnit 2.2 for our testing.
> > *
> > 4. Lightbox component will only work for IE 7 if served from
> > Tomcat *
> > IE 7's security features prevent our component from being loaded
> > directly from the hard drive. Therefore the component needs to
> > be deployed into Tomcat and served up. The obvious disadvantage
> > to this is that IE 7 testing will require users to have Tomcat
> > installed. Luckily if you are testing just the component, you
> > don't need to have any Sakai running which can speed things up
> > considerably.
> >
> >
> > With this in mind, if you are planning on demoing the component,
> > try to use Firefox 2.0+ if possible. If using IE 6 or 7 is
> > absolutely critical, please let me know and I'll walk you
> > through the process to get it working.
> >
> > We are currently doing research and testing various solutions.
> > Getting Lightbox working in IE is very important (goes without
> > saying) so we hope to get the most critical issues resolved soon.
> >
> > Questions? Comments? Need more detail? Let us know!
> >
> > Take care,
> >
> > - Jonathan.
> >
> > --
> > Jonathan Hung / _jonathan.hung at utoronto.ca_
> > <mailto:jonathan.hung at utoronto.ca>
> > University of Toronto - ATRC
> > Tel: (416) 946-8312
> >
> >
> >
> >
> > --
> > Jonathan Hung / _jonathan.hung at utoronto.ca_
> > <mailto:jonathan.hung at utoronto.ca>
> > University of Toronto - ATRC
> > Tel: (416) 946-8312 _______________________________________________
> > fluid-work mailing list
> > fluid-work at fluidproject.org
> > http://fluidproject.org/mailman/listinfo/fluid-work
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > fluid-work mailing list
> > fluid-work at fluidproject.org
> > http://fluidproject.org/mailman/listinfo/fluid-work
> >
> /(See attached file: elledge.vcf)/
>
(See attached file: elledge.vcf)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070702/c8401e01/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070702/c8401e01/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic22317.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070702/c8401e01/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070702/c8401e01/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: application/octet-stream
Size: 2 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070702/c8401e01/attachment.obj>
More information about the fluid-work
mailing list