Maintaining/announcing user focus [was Lightbox Component and IE 6 & 7 Compatibility]

Colin Clark colin.clark at utoronto.ca
Tue Jul 3 21:34:49 UTC 2007


Hi Mike,

When you're next in Toronto we can hook you up with the latest versions 
of JAWS and Window-Eyes and you can try them out on some user interfaces 
that have been marked up with ARIA roles and states, such as the 
Lightbox and the Dojo widgets we've been working on.

Keep in mind that one of the intentions of ARIA is to provide the 
*browser* with enough information about user interface elements within 
the document that it can translate these into objects in the native 
platform accessibility API. So, at least in principle, the reading 
behaviour of JAWS or other screen reader on a document element marked up 
with the aaa:combobox role should be the same as a combobox in a desktop 
GUI application. This is because they are both exposed to the assistive 
technology via MSAA on Windows.

Colin

Richard Schwerdtfeger wrote:
> Hi Michael,
> 
> Unless something is in focus we should probably not hear anything from 
> JAWS unless we flag it as different types of live region, alert, or 
> dialog box that comes up. These are areas which draw the users attention.
> 
> If the object is in focus then state changs should be conveyed. The only 
> other way JAWS could speak something is if a specific script was written 
> to do so. For example, we could create a status bar on the page and in 
> our application it may be best for JAWS to speak changes in status.
> 
> Beyond this, JAWS does not provide a UI style guide for how they present 
> things. I hope all this helps.
> 
> 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 04:45 PM
> 
> 	
> 
> To
> 	
> Richard 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]
> 
> 	
> 
> 
> Thanks, Rich. This is a helpful explanation. Do you know if Freedom
> Scientific has listed JAWS' response to various codes and contexts for
> roles and states? I'm trying envision the way that information will be
> relayed to users when there are changes to a page...
> 
> Mike
> 
> Richard Schwerdtfeger wrote:
>  >
>  > 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
>  > 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 02:26 PM
>  >
>  >
>  >
>  > To
>  >
>  > Richard 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)/
>  >
> /(See attached file: elledge.vcf)/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

-- 
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org



More information about the fluid-work mailing list