Autocomplete
Jörn Zaefferer
the jQuery UI team is working on an Autocomplete widget. We're looking for help with its accessibility. We've implemented ARIA attributes on the input (role:textbox, aria-autocomplete:list, aria-haspopup:true), the menu (role:menu, aria-activedescendent:ui-active-menuitem) and the menu-items (role:menuitem). Demos are available here: http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/ (start with default.html).
Jörn
Colin Clark
The new Autocomplete widget is really great! Fluid is already using it
in one of our museum products. I've been meaning for awhile to respond
to you about the a11y work you've done on it to see how we can help.
So, how can we help? Screen reader testing? Code review for your use
of ARIA? Other things?
Colin
> --
> You received this message because you are subscribed to the Google
> Groups "jQuery Accessibility" group.
> To post to this group, send email to jquer...@googlegroups.com.
> To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en
> .
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
Jörn Zaefferer
So if you could share some details on how you eg. do a screen reader test, that would be great.
Jörn
Jörn,
The new Autocomplete widget is really great! Fluid is already using it in one of our museum products. I've been meaning for awhile to respond to you about the a11y work you've done on it to see how we can help.
So, how can we help? Screen reader testing? Code review for your use of ARIA? Other things?
Colin
On 9-Jan-10, at 6:41 AM, Jörn Zaefferer wrote:
Hi,
the jQuery UI team is working on an Autocomplete widget. We're looking for help with its accessibility. We've implemented ARIA attributes on the input (role:textbox, aria-autocomplete:list, aria-haspopup:true), the menu (role:menu, aria-activedescendent:ui-active-menuitem) and the menu-items (role:menuitem). Demos are available here: http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/ (start with default.html).
Jörn
--
You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
Felix Nagel
Yours Felix Nagel
Colin Clark
We host Code Talks; thanks for mentioning it.
You're right that it can be very problematic for people who don't use
ATs on a regular basis to reliably test with them, but I thoroughly
disagree that it's a waste of time. Any testing is better than
nothing, but it's always best to have real users get involved, too.
Jörn, to answer your question, we have a few pages in the Fluid wiki
that describe the walkthrough procedures we tend to use when testing
for accessibility:
http://wiki.fluidproject.org/display/fluid/Accessibility+Review+Protocols
These don't go into great detail about testing with a screenreader nor
the specifics of ARIA, but they're a good start. Perhaps Alison or
others can chime in with their particular working process when testing
with assitive technologies.
Colin
On 11-Jan-10, at 1:14 PM, Felix Nagel wrote:
> Dont waste your time testing with screenreaders if you dont know
> how. Its very difficult for non disabled users to test with software
> like this. Better ask on twitter or at http://wiki.codetalks.org/
> for some testers.
>
> Yours Felix Nagel
>
> On Mon, Jan 11, 2010 at 18:24, Jörn Zaefferer <joern.z...@googlemail.com
> > wrote:
> Both screen reader testing and ARIA code review would be great. Or
> whatever you can come up with, I'm still a novice in this area. All
> I've done so far is a bit of testing with NVDA, but with no previous
> experience, I'm not sure what to do with the results...
---
Chris Westbrook
Scott González
Jörn Zaefferer
I think the Autocomplete itself (http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/default.html) is in a good state, at least from the point of view of the Simple Protocol. The keyboard focus is obvious, keyboard navigation works properly. What else is there?
Jörn
Hans Hillen
Below is my feedback to the combobox sample at
http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/combobox.html:
- The dropdown menu items are currently not announced by screen
readers. You can solve this in two ways:
1. Moving focus to the list. The moment you start highlighting items
in the list (after the user presses the up or down arrow keys), focus
placed on the list itself. When the list is closed (e.g. because esc.
was pressed or an item was selected) focus is placed back on the
textfield. Note that when you follow this approach, you'll have to
change the way you're currently using aria-activedescendant. The
intended use of this attribute is is to dynamically change its value
to the ID of the child element that is considered active. Instead,
you're keeping the aria-activedescendant value the same and you're
dynamically removing/adding that ID ("ui-active-menuitem") to the menu
items as the selection in the list is changed. This approach doesn't
work, because the browser and screen readers listen for a change in
aria-activedescendant, which doesn't occur. The only way a screen
reader would announce the newly active child element is if focus was
moved away from the list and back. So instead, give every item an ID,
and change the aria-activedescendant value on the list.
2. Leave keyboard input focus on the textfield, but use
activedescendant to programmatically set focus to the selected
menuitem . For this solution, you need to set the textfield's 'aria-
owns' attribute to the ID of the list (after it is added to the DOM).
When an autocomplete list item is highlighted, you also need to set
aria-activedescendant on the actual textfield rather than the list. So
as the user navgigates up or down the auto complete list, keyboard
focus remains on the textfield (the user can still type in here), but
you set the textfield's aria-activedescendant attribute to the newly
selected item in the list. This way it should be announced by the
screen reader.
- You need to wrap both the textfield and the dropdownlist in an
element with role="combobox", or associate the two with this element
using aria-owns.
- The lack of proper visual indication of focus is a problem
throughout most jQuery widgets, so we'll probably have to address it
on a larger scale (e.g. a universal theme for focus highlights that
all widgets inherit).
- It's not necessary to add the drop down button as a separate tab
stop, as keyboard users can already expand the list with the arrow
keys and an extra tabstop only clutters the tab order in this case. If
you really want to keep it in the tab order, you'll have to provide an
accessible name for it, for example through the aria-label or title
attribute.
Those are just the things I came up with, let me know what you think.
For more information about auto complete and ARIA, have a look at the
following resources:
- http://dev.aol.com/dhtml_style_guide#autocomplete
- http://www.w3.org/WAI/PF/aria/states_and_properties#aria-autocomplete
- http://www.w3.org/TR/wai-aria-practices/#autocomplete
If you have any questions or other people want to add anything, just
let me know.
Hans
On Jan 12, 10:01 am, Jörn Zaefferer <joern.zaeffe...@googlemail.com>
wrote:
> I took a look at the Simple Protocol (http://wiki.fluidproject.org/display/fluid/Simple+Accessibility+Revie...
> The widget is keyboard controllable, which is a good start, but has some
> issues: The button on the combobox demo (http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/c...)
> doesn't have a visual indication of keyboard focus. So while I can tab to
> the button and activate it with space and enter, I don't get a visual focus
> indication, so can only guess where the focus is. Also, when activating the
> button, the focus moves to the input.
>
> I think the Autocomplete itself (http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/d...)
> is in a good state, at least from the point of view of the Simple Protocol.
> The keyboard focus is obvious, keyboard navigation works properly. What else
> is there?
>
> Jörn
>
> On Mon, Jan 11, 2010 at 8:59 PM, Colin Clark <colinbdcl...@gmail.com> wrote:
> > Hi Felix,
>
> > We host Code Talks; thanks for mentioning it.
>
> > You're right that it can be very problematic for people who don't use ATs
> > on a regular basis to reliably test with them, but I thoroughly disagree
> > that it's a waste of time. Any testing is better than nothing, but it's
> > always best to have real users get involved, too.
>
> > Jörn, to answer your question, we have a few pages in the Fluid wiki that
> > describe the walkthrough procedures we tend to use when testing for
> > accessibility:
>
> >http://wiki.fluidproject.org/display/fluid/Accessibility+Review+Proto...
>
> > These don't go into great detail about testing with a screenreader nor the
> > specifics of ARIA, but they're a good start. Perhaps Alison or others can
> > chime in with their particular working process when testing with assitive
> > technologies.
>
> > Colin
>
> > On 11-Jan-10, at 1:14 PM, Felix Nagel wrote:
>
> > Dont waste your time testing with screenreaders if you dont know how. Its
> >> very difficult for non disabled users to test with software like this.
> >> Better ask on twitter or athttp://wiki.codetalks.org/for some testers.
>
> >> Yours Felix Nagel
>
> >> On Mon, Jan 11, 2010 at 18:24, Jörn Zaefferer <
> >> joern.zaeffe...@googlemail.com> wrote:
> >> Both screen reader testing and ARIA code review would be great. Or
> >> whatever you can come up with, I'm still a novice in this area. All I've
> >> done so far is a bit of testing with NVDA, but with no previous experience,
> >> I'm not sure what to do with the results...
>
> > ---
> > Colin Clark
> > Technical Lead, Fluid Project
> >http://fluidproject.org
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jQuery Accessibility" group.
> > To post to this group, send email to jquer...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jquery-a11y...@googlegroups.com<jquery-a11y%2Bunsu...@googlegroups.com>
Jörn Zaefferer
finally got around taking a look at this again. Based on what we have
so far, way number two would be a lot easier to implement.
- Currently the autocomplete widget uses the menu widget, which sets
the activedescendent attribute on itself. Should this be moved to the
input field? Or could be elements have the attribute?
- On wrapping with an element with role="combobox" or using aria-owns:
I see no technical issues with both, so which one is recommened?
- On extra tab stop for the button: Sounds like I should set
tabindex="-1" to the button to take it out of the tab order. Is that
correct?
I'll look into implementing these once the details are clear, then we
can do some more testing.
Regards
Jörn
> To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
Rich Caloggero
> change the way you're currently using aria-activedescendant. The
> intended use of this attribute is is to dynamically change its value
> to the ID of the child element that is considered active. Instead,
> you're keeping the aria-activedescendant value the same and you're
> dynamically removing/adding that ID ("ui-active-menuitem") to the menu
> items as the selection in the list is changed. This approach doesn't
> work, because the browser and screen readers listen for a change in
> aria-activedescendant, which doesn't occur. The only way a screen
> reader would announce the newly active child element is if focus was
> moved away from the list and back. So instead, give every item an ID,
> and change the aria-activedescendant value on the list.
>
How can you impelment a widgit like this? id values are supposed to be
unique throughout a document. What if your including widgits which use this
activedescendant in this way. How can you be sure that every
menu/list/whatever item in every widgit dropped into that page has unique
ids, especially when each item in the list must have its own id? This
really makes no sense to me. If IDs had element scope then this might make
sense, but unfortunately this isn't the case either.
Oddly enough, in jQuery-ui 1.8rc3, if you change the role from menu to
listbox on line 317 of jquery.ui.autocomplete.js, the widgit seems to work
with both Jaws and nvda; I made no other modifications.
How is activedescendant being used here?
Its being initialized to ui-active-menuitem, which is being placed on each
item as it becomes active. This seems logical to me. I cannot find the code,
but I did write a simple listbox demo which used just such an approach, and
it worked fine with Jaws. Maybe this isn't the way things were "intended"
to work, but I think this makes sense logically and does not require the
generation of IDS for each and every list or menu item you want to make
accessible.
Does this make sense? comments please.
-- Rich
----- Original Message -----
From: "Jörn Zaefferer" <joern.z...@googlemail.com>
To: "jquery-a11y" <jquer...@googlegroups.com>
Sent: Tuesday, March 30, 2010 3:13 PM
Subject: Re: Autocomplete
Hi Hans,
finally got around taking a look at this again. Based on what we have
so far, way number two would be a lot easier to implement.
- Currently the autocomplete widget uses the menu widget, which sets
the activedescendent attribute on itself. Should this be moved to the
input field? Or could be elements have the attribute?
- On wrapping with an element with role="combobox" or using aria-owns:
I see no technical issues with both, so which one is recommened?
- On extra tab stop for the button: Sounds like I should set
tabindex="-1" to the button to take it out of the tab order. Is that
correct?
I'll look into implementing these once the details are clear, then we
can do some more testing.
Regards
Jrn
On Wed, Feb 17, 2010 at 7:25 AM, Hans Hillen <hans....@gmail.com> wrote:
> Hi Jrn,
> On Jan 12, 10:01 am, Jrn Zaefferer <joern.zaeffe...@googlemail.com>
> wrote:
>> I took a look at the Simple Protocol
>> (http://wiki.fluidproject.org/display/fluid/Simple+Accessibility+Revie...
>> The widget is keyboard controllable, which is a good start, but has some
>> issues: The button on the combobox demo
>> (http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/c...)
>> doesn't have a visual indication of keyboard focus. So while I can tab to
>> the button and activate it with space and enter, I don't get a visual
>> focus
>> indication, so can only guess where the focus is. Also, when activating
>> the
>> button, the focus moves to the input.
>>
>> I think the Autocomplete itself
>> (http://jquery-ui.googlecode.com/svn/branches/dev/demos/autocomplete/d...)
>> is in a good state, at least from the point of view of the Simple
>> Protocol.
>> The keyboard focus is obvious, keyboard navigation works properly. What
>> else
>> is there?
>>
>> Jrn
>>
>> On Mon, Jan 11, 2010 at 8:59 PM, Colin Clark <colinbdcl...@gmail.com>
>> wrote:
>> > Hi Felix,
>>
>> > We host Code Talks; thanks for mentioning it.
>>
>> > You're right that it can be very problematic for people who don't use
>> > ATs
>> > on a regular basis to reliably test with them, but I thoroughly
>> > disagree
>> > that it's a waste of time. Any testing is better than nothing, but it's
>> > always best to have real users get involved, too.
>>
>> > Jrn, to answer your question, we have a few pages in the Fluid wiki
>> > that
>> > describe the walkthrough procedures we tend to use when testing for
>> > accessibility:
>>
>> >http://wiki.fluidproject.org/display/fluid/Accessibility+Review+Proto...
>>
>> > These don't go into great detail about testing with a screenreader nor
>> > the
>> > specifics of ARIA, but they're a good start. Perhaps Alison or others
>> > can
>> > chime in with their particular working process when testing with
>> > assitive
>> > technologies.
>>
>> > Colin
>>
>> > On 11-Jan-10, at 1:14 PM, Felix Nagel wrote:
>>
>> > Dont waste your time testing with screenreaders if you dont know how.
>> > Its
>> >> very difficult for non disabled users to test with software like this.
>> >> Better ask on twitter or athttp://wiki.codetalks.org/for some testers.
>>
>> >> Yours Felix Nagel
>>
>> >> On Mon, Jan 11, 2010 at 18:24, Jrn Zaefferer <
Rich Caloggero
1. Have a single ID (ui-active-menuitem) which moves depending on which item
is active;
2. update aria-activedescendant each time you move the id
This allows you to have one ID string used for this purpose, so you don't
need to give each element in the menu a unique id.