Maintaining/announcing user focus [was Lightbox Component and IE 6 & 7 Compatibility]
Michael S Elledge
elledge at msu.edu
Tue Jul 3 21:54:56 UTC 2007
That sounds great, Colin. Between you and Rich this is making more
sense. I'm very interested to see what additional information we can
provide for persons with disabilities, without confusing or overwhelming
them, and in what circumstances functionality should be fully
transparent. Does anyone know of any research into that...or maybe
that's an opportunity for Fluid user testing?
Mike
Colin Clark wrote:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 136 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070703/ecdb7fb4/attachment.vcf>
More information about the fluid-work
mailing list