I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
We do have plans to release a multi word autocomplete ( http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu ( http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI ( http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
Right now I see two places where you could easily help out: 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. 2) Fork jQuery UI on GitHub and send pull requests.
Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote: > Good evening,
> I tested the jQuery UI autocomplete plugin today at > http://jqueryui.com/demos/autocomplete/multiple.html . We are considering > adopting this plugin in Drupal Core, and I tested quickly to see if it was > accessible to screen-reader users (not that this is our only group to be > concerned about, it was just quick). I noticed thatit does not appear to > work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
> I skimmed briefly over the plugin source and it doesn't appear to be using > ARIA correctly. I would like to help to improve the plugin, but am not > familiar with the jQuery UI community / development cycles etc.
> It would be really helpful if someone could tell me if there is a more > recent version that I should be testing, and if there is a demo somewhere > (note we need the multiple values autocomplete). Also, if someone could > provide me with a primer to the community, sites used, etc, that would be > greatly appreciated.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Monday, November 08, 2010 8:35 AM Subject: Re: jQuery UI autocomplete plugin
Hey Everett,
The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
Right now I see two places where you could easily help out: 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. 2) Fork jQuery UI on GitHub and send pull requests.
Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
Good evening,
I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
That's interesting, because all of the demos use the same roles and ARIA attributes.
The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org>wrote:
> I remember looking at and commenting about this about a year ago. I > tested the autocomplete with Jaws (version 10.xx at the time). I found that > the use of role="menu" causes problems for Jaws. I suggested they use a role > of "list" on the menu and it seemed to work better. I need to look back at > the code, but from the brief test of the online demos, I find that the > default case works and the others seem not to work. Maybe only the default > case got the updated role?
> -- Rich
> ----- Original Message ----- > *From:* Scott González <scott.gonza...@gmail.com> > *To:* jquery-a11y@googlegroups.com > *Sent:* Monday, November 08, 2010 8:35 AM > *Subject:* Re: jQuery UI autocomplete plugin
> Hey Everett,
> The demo you were looking at is running the most recent stable release, so > that's a good place to be looking. We also have > http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is > running the same demo straight from the master branch of our git repo > (currently down, GitHub just changed their API which broke our site; we're > working on bringing it back up).
> One thing to note is that the multiple word support is just a demo built on > top of our single word autocomplete widget. What that means is there's no > official support for it: no tests, no documentation, may not have a full > API, etc. However, we do try to provide as much support for them as we > reasonably can, so if you'd like to help improve the multiple word demos, > we'd certainly appreciate any help.
> For a quick overview of our process: we design our plugins on our planning > wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and > API design. Once we've got an idea of what we want to build, we'll prototype > the plugin in a branch, figure out which parts of our design are working > well, which aren't and where any holes might exist. Then we iterate on the > design and flesh out the rest of the code. Once the API and code are mostly > stable, we'll pull the plugin into the master branch, and it will be > released in the next major version.
> We do have plans to release a multi word autocomplete ( > http://wiki.jqueryui.com/ListBuilder) which will be built on top of > autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu ( > http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been > officially released, but if you look at the bottom of > jquery.ui.autocomplete.js, you'll see that there's an initial implementation > of menu in there. That menu plugin has since had a lot of improvements in > our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu > is slated for our next major version (1.9), though it has not yet been > pulled into the master branch.
> We do have some ARIA attributes in both the autocomplete and menu plugins. > So it's probably best to start with just single word autocomplete and verify > that it's fully accessible and then move on to multi word autocomplete.
> Almost all of our discussion for everything jQuery-related happens on the > jQuery Forums (http://forum.jquery.com). There are two forums specifically > for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) > for people using existing plugins and Developing jQuery UI ( > http://forum.jquery.com/developing-jquery-ui) for people building official > jQuery UI plugins. However, we still use this Google Group for accessibility > discussions because Zoho, our forum software, has some accessibility issues > which obviously prevents many of the people interested in helping out with > accessibility from being able to do so.
> Right now I see two places where you could easily help out: > 1) Fill out any missing accessibility information on the planning wiki for > menu and autocomplete, possibly list builder as well. > 2) Fork jQuery UI on GitHub and send pull requests.
> Any other types of contributions would be appreciated as well and if you > have any questions feel free to post them here or on the main forums (if > they're just general questions, the forums are probably better since they > receive much higher traffic).
> On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
>> Good evening,
>> I tested the jQuery UI autocomplete plugin today at >> http://jqueryui.com/demos/autocomplete/multiple.html . We are >> considering adopting this plugin in Drupal Core, and I tested quickly to see >> if it was accessible to screen-reader users (not that this is our only group >> to be concerned about, it was just quick). I noticed thatit does not appear >> to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
>> I skimmed briefly over the plugin source and it doesn't appear to be using >> ARIA correctly. I would like to help to improve the plugin, but am not >> familiar with the jQuery UI community / development cycles etc.
>> It would be really helpful if someone could tell me if there is a more >> recent version that I should be testing, and if there is a demo somewhere >> (note we need the multiple values autocomplete). Also, if someone could >> provide me with a primer to the community, sites used, etc, that would be >> greatly appreciated.
>> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
This time, I was able to get all the demos to work except both of the multiple values demos.
The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
Why is this demo different? Again, how is it supposed to work for sighted folks?
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Tuesday, November 09, 2010 2:27 PM Subject: Re: jQuery UI autocomplete plugin
That's interesting, because all of the demos use the same roles and ARIA attributes.
The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
-- Rich
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Monday, November 08, 2010 8:35 AM Subject: Re: jQuery UI autocomplete plugin
Hey Everett,
The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
Right now I see two places where you could easily help out: 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. 2) Fork jQuery UI on GitHub and send pull requests.
Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
Good evening,
I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org>wrote:
> OK, I took another look with NVDA screen reader.
> This time, I was able to get all the demos to work except both of the > multiple values demos.
> The other demos would cycle through the values in the menu when the arrow > keys were used while focused on the text input field. Each time an up/down > arrow is pressed, a value in the list is stuck into the field and the screen > reader reads it. The multiple values demo does not seem to work this way. > In fact, I'm not sure what's going on on-screen at all here. How is it > supposed to work? Does it work from the keyboard without a screen reader > active?
> If I type a coupel characters then use an arrow key, tab away from the > field, then tab back again, there seems to be a value from the list in the > field and the screen reader will read it. To change and hear the next value, > I need to press downArrow, tab away, tab back, then press a key to have the > screen reader read the content of the field again.
> Why is this demo different? Again, how is it supposed to work for sighted > folks?
> -- Rich
> ----- Original Message ----- > *From:* Scott González <scott.gonza...@gmail.com> > *To:* jquery-a11y@googlegroups.com > *Sent:* Tuesday, November 09, 2010 2:27 PM > *Subject:* Re: jQuery UI autocomplete plugin
> That's interesting, because all of the demos use the same roles and ARIA > attributes.
> The text field has role=textbox, aria-autocomplete=list, > aria-haspopup=true. > The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we > use a roaming id on the menu items.
> On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org>wrote:
>> I remember looking at and commenting about this about a year ago. I >> tested the autocomplete with Jaws (version 10.xx at the time). I found that >> the use of role="menu" causes problems for Jaws. I suggested they use a role >> of "list" on the menu and it seemed to work better. I need to look back at >> the code, but from the brief test of the online demos, I find that the >> default case works and the others seem not to work. Maybe only the default >> case got the updated role?
>> -- Rich
>> ----- Original Message ----- >> *From:* Scott González <scott.gonza...@gmail.com> >> *To:* jquery-a11y@googlegroups.com >> *Sent:* Monday, November 08, 2010 8:35 AM >> *Subject:* Re: jQuery UI autocomplete plugin
>> Hey Everett,
>> The demo you were looking at is running the most recent stable release, so >> that's a good place to be looking. We also have >> http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is >> running the same demo straight from the master branch of our git repo >> (currently down, GitHub just changed their API which broke our site; we're >> working on bringing it back up).
>> One thing to note is that the multiple word support is just a demo built >> on top of our single word autocomplete widget. What that means is there's no >> official support for it: no tests, no documentation, may not have a full >> API, etc. However, we do try to provide as much support for them as we >> reasonably can, so if you'd like to help improve the multiple word demos, >> we'd certainly appreciate any help.
>> For a quick overview of our process: we design our plugins on our planning >> wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and >> API design. Once we've got an idea of what we want to build, we'll prototype >> the plugin in a branch, figure out which parts of our design are working >> well, which aren't and where any holes might exist. Then we iterate on the >> design and flesh out the rest of the code. Once the API and code are mostly >> stable, we'll pull the plugin into the master branch, and it will be >> released in the next major version.
>> We do have plans to release a multi word autocomplete ( >> http://wiki.jqueryui.com/ListBuilder) which will be built on top of >> autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu >> (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been >> officially released, but if you look at the bottom of >> jquery.ui.autocomplete.js, you'll see that there's an initial implementation >> of menu in there. That menu plugin has since had a lot of improvements in >> our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu >> is slated for our next major version (1.9), though it has not yet been >> pulled into the master branch.
>> We do have some ARIA attributes in both the autocomplete and menu plugins. >> So it's probably best to start with just single word autocomplete and verify >> that it's fully accessible and then move on to multi word autocomplete.
>> Almost all of our discussion for everything jQuery-related happens on the >> jQuery Forums (http://forum.jquery.com). There are two forums >> specifically for jQuery UI: Using jQuery UI ( >> http://forum.jquery.com/using-jquery-ui) for people using existing >> plugins and Developing jQuery UI ( >> http://forum.jquery.com/developing-jquery-ui) for people building >> official jQuery UI plugins. However, we still use this Google Group for >> accessibility discussions because Zoho, our forum software, has some >> accessibility issues which obviously prevents many of the people interested >> in helping out with accessibility from being able to do so.
>> Right now I see two places where you could easily help out: >> 1) Fill out any missing accessibility information on the planning wiki for >> menu and autocomplete, possibly list builder as well. >> 2) Fork jQuery UI on GitHub and send pull requests.
>> Any other types of contributions would be appreciated as well and if you >> have any questions feel free to post them here or on the main forums (if >> they're just general questions, the forums are probably better since they >> receive much higher traffic).
>> On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
>>> Good evening,
>>> I tested the jQuery UI autocomplete plugin today at >>> http://jqueryui.com/demos/autocomplete/multiple.html . We are >>> considering adopting this plugin in Drupal Core, and I tested quickly to see >>> if it was accessible to screen-reader users (not that this is our only group >>> to be concerned about, it was just quick). I noticed thatit does not appear >>> to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
>>> I skimmed briefly over the plugin source and it doesn't appear to be >>> using ARIA correctly. I would like to help to improve the plugin, but am >>> not familiar with the jQuery UI community / development cycles etc.
>>> It would be really helpful if someone could tell me if there is a more >>> recent version that I should be testing, and if there is a demo somewhere >>> (note we need the multiple values autocomplete). Also, if someone could >>> provide me with a primer to the community, sites used, etc, that would be >>> greatly appreciated.
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "jQuery Accessibility" group. >>> To post to this group, send email to jquery-a11y@googlegroups.com. >>> To unsubscribe from this group, send email to >>> jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at
Well, it sort of works. I can press downArrow then enter and get something in the field. Just typing downArrow with no characters in the field doesn't show me anything; I need to press enter and then I get one value and a comma. I can't seem to just browse the list.
The other weirdness is that unlike the other cases, I cannot use the arrow keys or enter without jaws tossing me out of the field; I have to preceed each arrow press with the jaws pass-next-key-through key. Perhaps the default demo uses role="application" somewhere (on the text field or perhaps the plugin is adding it? This will generally keep the focus in that field regardless of what keys are press. Actually, there are a couple of screen reader keys you can hit to escape back to browse mode...
The only way to look at two different points on the screen at once with a screen reader is to keep focus on one and use liveregion markup on the other so we can hear the updates as they are made. If we mark up the menu as a live region, then perhaps the values will be spoken when they are highlighted?
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Tuesday, November 09, 2010 3:47 PM Subject: Re: jQuery UI autocomplete plugin
The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
OK, I took another look with NVDA screen reader.
This time, I was able to get all the demos to work except both of the multiple values demos.
The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
Why is this demo different? Again, how is it supposed to work for sighted folks?
-- Rich
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Tuesday, November 09, 2010 2:27 PM Subject: Re: jQuery UI autocomplete plugin
That's interesting, because all of the demos use the same roles and ARIA attributes.
The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
-- Rich
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Monday, November 08, 2010 8:35 AM Subject: Re: jQuery UI autocomplete plugin
Hey Everett,
The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
Right now I see two places where you could easily help out: 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. 2) Fork jQuery UI on GitHub and send pull requests.
Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
Good evening,
I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
Having done no testing I believe that you are correct. I do not believe that AT will announce a change to the selected item in a list if the list does not have focus. This again runs into the problem of wanting to keep the focus in the textfield, while being able to announce the changes to AT.
This would seem to be a logical presumption as to why Rich is experiencing the results that he has reported.
The interim solution that I am trying to get committed to the Drupal 7 custom autocomplete is to use a live region to announce the selected list item. This way we wouldn't need to switch focus back and forth between the two UI components (really 1 compound component. I am not suggesting that this is the best approach, but I thought I'd throw it out there FWIW.
> The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
> Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
> It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
> On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: > OK, I took another look with NVDA screen reader.
> This time, I was able to get all the demos to work except both of the multiple values demos.
> The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
> If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
> Why is this demo different? Again, how is it supposed to work for sighted folks?
> -- Rich
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Tuesday, November 09, 2010 2:27 PM > Subject: Re: jQuery UI autocomplete plugin
> That's interesting, because all of the demos use the same roles and ARIA attributes.
> The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. > The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
> On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: > I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
> -- Rich
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Monday, November 08, 2010 8:35 AM > Subject: Re: jQuery UI autocomplete plugin
> Hey Everett,
> The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
> One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
> For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
> We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
> We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
> Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
> Right now I see two places where you could easily help out: > 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. > 2) Fork jQuery UI on GitHub and send pull requests.
> Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
> On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote: > Good evening,
> I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
> I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
> It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to
Agreed that aria role="application" needs to be used in the container for the widget to keep screen-readers in forms / application mode, so that arrow keys don't exit the textfield. I don't think that using aria-live on the list will speak the selected item, since it is selected by setting an id / css class, but it would be worth testing.
The options are, AFAIK, to set the focus to the listbox, or to use a separate live region to announce the changes, but this needs testing.
There could also be other options. I'll take a look through codetalk.org when I can to see if I can find a good example.
> Well, it sort of works. I can press downArrow then enter and get something in the field. Just typing downArrow with no characters in the field doesn't show me anything; I need to press enter and then I get one value and a comma. I can't seem to just browse the list.
> The other weirdness is that unlike the other cases, I cannot use the arrow keys or enter without jaws tossing me out of the field; I have to preceed each arrow press with the jaws pass-next-key-through key. Perhaps the default demo uses role="application" somewhere (on the text field or perhaps the plugin is adding it? This will generally keep the focus in that field regardless of what keys are press. Actually, there are a couple of screen reader keys you can hit to escape back to browse mode...
> The only way to look at two different points on the screen at once with a screen reader is to keep focus on one and use liveregion markup on the other so we can hear the updates as they are made. > If we mark up the menu as a live region, then perhaps the values will be spoken when they are highlighted?
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Tuesday, November 09, 2010 3:47 PM > Subject: Re: jQuery UI autocomplete plugin
> The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
> Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
> It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
> On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: > OK, I took another look with NVDA screen reader.
> This time, I was able to get all the demos to work except both of the multiple values demos.
> The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
> If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
> Why is this demo different? Again, how is it supposed to work for sighted folks?
> -- Rich
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Tuesday, November 09, 2010 2:27 PM > Subject: Re: jQuery UI autocomplete plugin
> That's interesting, because all of the demos use the same roles and ARIA attributes.
> The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. > The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
> On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: > I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
> -- Rich
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Monday, November 08, 2010 8:35 AM > Subject: Re: jQuery UI autocomplete plugin
> Hey Everett,
> The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
> One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
> For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
> We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
> We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
> Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
> Right now I see two places where you could easily help out: > 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. > 2) Fork jQuery UI on GitHub and send pull requests.
> Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
> On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote: > Good evening,
> I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
> I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
> It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
I've played with the code a bit, but am still confused about what is going on visually. See attached source.
I've added aria-live="assertive" to the body tag so I can hear any changes made on the page at all (definately not something you'd do for the release). I also wrapped the input element in a div with role="application" which should help jaws keep the focus on the form field when you start pressing arrow keys.
What I'm hearing is the menu changing when I type characters (very good). Arrow keys don't seem to do anything. I've preferenced them with the jaws (pass through next key) command (jawsKey+shift+3 on the number row); press this and then the key you want to pass through. I think the arrows must just be highlighting part of the menu, but not changing anything.
A quick fix might be to place a liveregion attribute on the menu, then when you move the highlight, rewrite the element that you ultimately highlight. This causes the text to change, and thus the liveregion to trigger. It will not trigger based on color / text attribute changes.
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Tuesday, November 09, 2010 3:47 PM Subject: Re: jQuery UI autocomplete plugin
The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
OK, I took another look with NVDA screen reader.
This time, I was able to get all the demos to work except both of the multiple values demos.
The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
Why is this demo different? Again, how is it supposed to work for sighted folks?
-- Rich
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Tuesday, November 09, 2010 2:27 PM Subject: Re: jQuery UI autocomplete plugin
That's interesting, because all of the demos use the same roles and ARIA attributes.
The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
-- Rich
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Monday, November 08, 2010 8:35 AM Subject: Re: jQuery UI autocomplete plugin
Hey Everett,
The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
Right now I see two places where you could easily help out: 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. 2) Fork jQuery UI on GitHub and send pull requests.
Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
Good evening,
I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
Just taking a shot in the dark here, since I haven't tested. But, if we put aria-owns on the textbox, and set its value to the id of the listbox, AT * might * announce the changes in active-descendant.
> I've played with the code a bit, but am still confused about what is going on visually. See attached source.
> I've added aria-live="assertive" to the body tag so I can hear any changes made on the page at all (definately not something you'd do for the release). I also wrapped the input element in a div with role="application" which should help jaws keep the focus on the form field when you start pressing arrow keys.
> What I'm hearing is the menu changing when I type characters (very good). Arrow keys don't seem to do anything. I've preferenced them with the jaws (pass through next key) command (jawsKey+shift+3 on the number row); press this and then the key you want to pass through. I think the arrows must just be highlighting part of the menu, but not changing anything.
> A quick fix might be to place a liveregion attribute on the menu, then when you move the highlight, rewrite the element that you ultimately highlight. This causes the text to change, and thus the liveregion to trigger. It will not trigger based on color / text attribute changes.
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Tuesday, November 09, 2010 3:47 PM > Subject: Re: jQuery UI autocomplete plugin
> The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
> Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
> It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
> On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: > OK, I took another look with NVDA screen reader.
> This time, I was able to get all the demos to work except both of the multiple values demos.
> The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
> If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
> Why is this demo different? Again, how is it supposed to work for sighted folks?
> -- Rich
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Tuesday, November 09, 2010 2:27 PM > Subject: Re: jQuery UI autocomplete plugin
> That's interesting, because all of the demos use the same roles and ARIA attributes.
> The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. > The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
> On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: > I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
> -- Rich
> ----- Original Message ----- > From: Scott González > To: jquery-a11y@googlegroups.com > Sent: Monday, November 08, 2010 8:35 AM > Subject: Re: jQuery UI autocomplete plugin
> Hey Everett,
> The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
> One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
> For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
> We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
> We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
> Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
> Right now I see two places where you could easily help out: > 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. > 2) Fork jQuery UI on GitHub and send pull requests.
> Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
> On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote: > Good evening,
> I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to be concerned about, it was just quick). I noticed thatit does not appear to work for screen-reader users, testing with JAWS 11.0.1467 / FF 3.6.
> I skimmed briefly over the plugin source and it doesn't appear to be using ARIA correctly. I would like to help to improve the plugin, but am not familiar with the jQuery UI community / development cycles etc.
> It would be really helpful if someone could tell me if there is a more recent version that I should be testing, and if there is a demo somewhere (note we need the multiple values autocomplete). Also, if someone could provide me with a primer to the community, sites used, etc, that would be greatly appreciated.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
Thanks, Everett Zufelt Accessibility Consultant & Web Developer
Web http://zufelt.ca Phone (toll free U.S. & Canada) 1-877-ZUFELT-8 (1-877-983-3588)
> Just taking a shot in the dark here, since I haven't tested. But, if we put aria-owns on the textbox, and set its value to the id of the listbox, AT * might * announce the changes in active-descendant.
> On 2010-11-10, at 5:23 PM, Rich Caloggero wrote:
>> I've played with the code a bit, but am still confused about what is going on visually. See attached source.
>> I've added aria-live="assertive" to the body tag so I can hear any changes made on the page at all (definately not something you'd do for the release). I also wrapped the input element in a div with role="application" which should help jaws keep the focus on the form field when you start pressing arrow keys.
>> What I'm hearing is the menu changing when I type characters (very good). Arrow keys don't seem to do anything. I've preferenced them with the jaws (pass through next key) command (jawsKey+shift+3 on the number row); press this and then the key you want to pass through. I think the arrows must just be highlighting part of the menu, but not changing anything.
>> A quick fix might be to place a liveregion attribute on the menu, then when you move the highlight, rewrite the element that you ultimately highlight. This causes the text to change, and thus the liveregion to trigger. It will not trigger based on color / text attribute changes.
>> ----- Original Message ----- >> From: Scott González >> To: jquery-a11y@googlegroups.com >> Sent: Tuesday, November 09, 2010 3:47 PM >> Subject: Re: jQuery UI autocomplete plugin
>> The difference in implementation is that when using multiple words, we don't populate the text field, we only highlight the menu item and update the roaming id (for the active descendant).
>> Try typing "a", press the down arrow, then press enter. You should get ActionScript followed by a comma and a space in the text field. You can then type more characters and get results again (for example, you could repeat this steps ten times and get ActionScript written ten times in the text field). You can also just press the down arrow without typing anything and see the full list of possible words.
>> It sounds like updating the active descendant isn't actually doing anything for you and you're only hearing updates in the other demos because we're actively changing the value of the focused text field. Perhaps the menu needs to have focus in order for the active descendant to matter? The problem with that is we want to keep the focus on the text field so the user can type whenever they want.
>> On Tue, Nov 9, 2010 at 3:11 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: >> OK, I took another look with NVDA screen reader.
>> This time, I was able to get all the demos to work except both of the multiple values demos.
>> The other demos would cycle through the values in the menu when the arrow keys were used while focused on the text input field. Each time an up/down arrow is pressed, a value in the list is stuck into the field and the screen reader reads it. The multiple values demo does not seem to work this way. In fact, I'm not sure what's going on on-screen at all here. How is it supposed to work? Does it work from the keyboard without a screen reader active?
>> If I type a coupel characters then use an arrow key, tab away from the field, then tab back again, there seems to be a value from the list in the field and the screen reader will read it. To change and hear the next value, I need to press downArrow, tab away, tab back, then press a key to have the screen reader read the content of the field again.
>> Why is this demo different? Again, how is it supposed to work for sighted folks?
>> -- Rich
>> ----- Original Message ----- >> From: Scott González >> To: jquery-a11y@googlegroups.com >> Sent: Tuesday, November 09, 2010 2:27 PM >> Subject: Re: jQuery UI autocomplete plugin
>> That's interesting, because all of the demos use the same roles and ARIA attributes.
>> The text field has role=textbox, aria-autocomplete=list, aria-haspopup=true. >> The menu has role=listbox, aria-activedescendant=ui-active-menuitem and we use a roaming id on the menu items.
>> On Tue, Nov 9, 2010 at 2:19 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote: >> I remember looking at and commenting about this about a year ago. I tested the autocomplete with Jaws (version 10.xx at the time). I found that the use of role="menu" causes problems for Jaws. I suggested they use a role of "list" on the menu and it seemed to work better. I need to look back at the code, but from the brief test of the online demos, I find that the default case works and the others seem not to work. Maybe only the default case got the updated role?
>> -- Rich
>> ----- Original Message ----- >> From: Scott González >> To: jquery-a11y@googlegroups.com >> Sent: Monday, November 08, 2010 8:35 AM >> Subject: Re: jQuery UI autocomplete plugin
>> Hey Everett,
>> The demo you were looking at is running the most recent stable release, so that's a good place to be looking. We also have http://view.jqueryui.com/master/demos/autocomplete/multiple.html which is running the same demo straight from the master branch of our git repo (currently down, GitHub just changed their API which broke our site; we're working on bringing it back up).
>> One thing to note is that the multiple word support is just a demo built on top of our single word autocomplete widget. What that means is there's no official support for it: no tests, no documentation, may not have a full API, etc. However, we do try to provide as much support for them as we reasonably can, so if you'd like to help improve the multiple word demos, we'd certainly appreciate any help.
>> For a quick overview of our process: we design our plugins on our planning wiki (http://wiki.jqueryui.com). This wiki contains markup, visual, and API design. Once we've got an idea of what we want to build, we'll prototype the plugin in a branch, figure out which parts of our design are working well, which aren't and where any holes might exist. Then we iterate on the design and flesh out the rest of the code. Once the API and code are mostly stable, we'll pull the plugin into the master branch, and it will be released in the next major version.
>> We do have plans to release a multi word autocomplete (http://wiki.jqueryui.com/ListBuilder) which will be built on top of autocomplete (http://wiki.jqueryui.com/Autocomplete) which utilizes menu (http://wiki.jqueryui.com/Menu). Right now the menu plugin hasn't been officially released, but if you look at the bottom of jquery.ui.autocomplete.js, you'll see that there's an initial implementation of menu in there. That menu plugin has since had a lot of improvements in our menu branch (https://github.com/jquery/jquery-ui/tree/menu) and menu is slated for our next major version (1.9), though it has not yet been pulled into the master branch.
>> We do have some ARIA attributes in both the autocomplete and menu plugins. So it's probably best to start with just single word autocomplete and verify that it's fully accessible and then move on to multi word autocomplete.
>> Almost all of our discussion for everything jQuery-related happens on the jQuery Forums (http://forum.jquery.com). There are two forums specifically for jQuery UI: Using jQuery UI (http://forum.jquery.com/using-jquery-ui) for people using existing plugins and Developing jQuery UI (http://forum.jquery.com/developing-jquery-ui) for people building official jQuery UI plugins. However, we still use this Google Group for accessibility discussions because Zoho, our forum software, has some accessibility issues which obviously prevents many of the people interested in helping out with accessibility from being able to do so.
>> Right now I see two places where you could easily help out: >> 1) Fill out any missing accessibility information on the planning wiki for menu and autocomplete, possibly list builder as well. >> 2) Fork jQuery UI on GitHub and send pull requests.
>> Any other types of contributions would be appreciated as well and if you have any questions feel free to post them here or on the main forums (if they're just general questions, the forums are probably better since they receive much higher traffic).
>> On Mon, Nov 8, 2010 at 12:11 AM, E.J. Zufelt <li...@zufelt.ca> wrote: >> Good evening,
>> I tested the jQuery UI autocomplete plugin today at http://jqueryui.com/demos/autocomplete/multiple.html . We are considering adopting this plugin in Drupal Core, and I tested quickly to see if it was accessible to screen-reader users (not that this is our only group to
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote: > Another thought, I am writing quickly so I haven't looked back at the code.
> If I recall correctly the autocomplete isn't actually changing the active > descendant. It is, in the fact that it is changing the listitem that has > the active descendant id, but it isn't actually changing the value of the > active descendant property itself. This might mean that UAs aren't firing > the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
> Also, if I recall, there is no way to specify a prefix to the ids for the > widget, meaning possibly that the widget can only be used once per page. > This would probably make it difficult to use in a system like Drupal where > it may need to appear multiple times on the same page. Perhaps there is a > way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using.
What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
Thoughts...? -- Rich
From: Scott González Sent: Thursday, November 11, 2010 1:21 PM To: jquery-a11y@googlegroups.com Subject: Re: jQuery UI autocomplete plugin
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
From what I know of active descendant, its purpose is to determine which descendant element of a compound UI component has focus, so that the developer doesn't need to handle focus within the component. For example, set focus to a menu, and then set the active descendant to the selected / active menu item. This is why it is almost certainly necessary to have focus on the compound UI component (in the case of autocomplete listbox) in order for AT to announce the change in focus / active descendant.
> What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. > Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
> Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
> Thoughts...? > -- Rich
> From: Scott González > Sent: Thursday, November 11, 2010 1:21 PM > To: jquery-a11y@googlegroups.com > Subject: Re: jQuery UI autocomplete plugin
> On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote: > Another thought, I am writing quickly so I haven't looked back at the code.
> If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
> We should verify whether the current model works in a simplified test case.
> Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
> This is a known limitation that needs to be fixed in the menu widget that autocomplete is using. > -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
The little test program (at the above url) has only a single ul element with three list items beneath it. Its role is set to menu, and each li element has its role set to menuitem. The ul element has a keydown handler on it looking for up/down arrow keys. It can only be triggered when the ul item has focus. The ul item has tabindex of 0.
Jaws, and nvda, both can tab to the ul element, they call it a menu, and the key events get triggered. I'm sure the id referred to by activedescendant is valid and attached to a list item. If I press jawsKey+tab when focused on the ul element, it will read the li item with focus. When you first load the page, the third item has focus and jaws reports it as so when using jawsKey+tab.
When I arrow up or down, nothing is spoken. After pressing an arrow and I press jawsKey+tab, jaws still says the previous item with focus (item 3 if you've just loaded the page). However, if I press an arrow, tab away from the ul element, then tab back again and hit jawsKey+tab, it now reads the text of a different li - the one whose id is referenced by activedescendant.
So, where is the bug? I suspect Firefox is not sending the right stuff via the accessibility layer to the assistive technology. I suspect this since both Jaws and nvda exhibit the same seemingly incorrect behavior.
----- Original Message ----- From: E.J. Zufelt To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 12:35 AM Subject: Re: jQuery UI autocomplete plugin
From what I know of active descendant, its purpose is to determine which descendant element of a compound UI component has focus, so that the developer doesn't need to handle focus within the component. For example, set focus to a menu, and then set the active descendant to the selected / active menu item. This is why it is almost certainly necessary to have focus on the compound UI component (in the case of autocomplete listbox) in order for AT to announce the change in focus / active descendant.
What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
Thoughts...? -- Rich
From: Scott González Sent: Thursday, November 11, 2010 1:21 PM To: jquery-a11y@googlegroups.com Subject: Re: jQuery UI autocomplete plugin
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
My guess is that AT devices are only looking for changes to the aria-activedescendant attribute. When we're changing which element has the id, that might not be something they're looking for. What happens if you change the test to move the id to the appropriate element, then remove the aria-activedescendant attribute and then immediately add it back with the same value? If that works, what happens if you just set it back to its currently value without explicitly removing it in between?
> The little test program (at the above url) has only a single ul element > with three list items beneath it. Its role is set to menu, and each li > element has its role set to menuitem. The ul element has a keydown handler > on it looking for up/down arrow keys. It can only be triggered when the ul > item has focus. The ul item has tabindex of 0.
> Jaws, and nvda, both can tab to the ul element, they call it a menu, and > the key events get triggered. I'm sure the id referred to by > activedescendant is valid and attached to a list item. If I press > jawsKey+tab when focused on the ul element, it will read the li item with > focus. When you first load the page, the third item has focus and jaws > reports it as so when using jawsKey+tab.
> When I arrow up or down, nothing is spoken. After pressing an arrow and I > press jawsKey+tab, jaws still says the previous item with focus (item 3 if > you've just loaded the page). However, if I press an arrow, tab away from > the ul element, then tab back again and hit jawsKey+tab, it now reads the > text of a different li - the one whose id is referenced by activedescendant.
> So, where is the bug? I suspect Firefox is not sending the right stuff via > the accessibility layer to the assistive technology. I suspect this since > both Jaws and nvda exhibit the same seemingly incorrect behavior.
> Thoughts, comments, corrections? > -- Rich
> ----- Original Message ----- > *From:* E.J. Zufelt <li...@zufelt.ca> > *To:* jquery-a11y@googlegroups.com > *Sent:* Friday, November 12, 2010 12:35 AM > *Subject:* Re: jQuery UI autocomplete plugin
> From what I know of active descendant, its purpose is to determine which > descendant element of a compound UI component has focus, so that the > developer doesn't need to handle focus within the component. For example, > set focus to a menu, and then set the active descendant to the selected / > active menu item. This is why it is almost certainly necessary to have > focus on the compound UI component (in the case of autocomplete listbox) in > order for AT to announce the change in focus / active descendant.
> What happens is that when you focus on the menu (second tabstop on the > page), you hear jaws announce the menu item with the id that > aria-activedescendant references. However, when you change the item to > which aria-activedescendant references, jaws (and nvda) do not announce the > new state until you tab away from the element and then back again. You can > verify this using this test case. > Uncommenting the last alert in the handler shows that the correct item is > being chosen, and Jaws does report it when you tab away and back again.
> Its odd that both jaws and nvda have this behavior. Seems like a bug, but > perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
> On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
>> Another thought, I am writing quickly so I haven't looked back at the >> code.
>> If I recall correctly the autocomplete isn't actually changing the active >> descendant. It is, in the fact that it is changing the listitem that has >> the active descendant id, but it isn't actually changing the value of the >> active descendant property itself. This might mean that UAs aren't firing >> the correct events to have the change tracked.
> We should verify whether the current model works in a simplified test case.
>> Also, if I recall, there is no way to specify a prefix to the ids for >> the widget, meaning possibly that the widget can only be used once per >> page. This would probably make it difficult to use in a system like Drupal >> where it may need to appear multiple times on the same page. Perhaps there >> is a way to do this currently that I am missing.
> This is a known limitation that needs to be fixed in the menu widget that > autocomplete is using. > -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
OK, I've got it to work. It was your suggestion Scott which fixed the problem. The steps you must follow are: 1. remove the aria-activedescendant attribute altogether from the container; 2. move your chosen id string from the old menu item to the new one; 3. add the aria-activedescendant attribute back to the container, referring to the chosen id string.
I've used the convention that the chosen activedescendant id for this container is the container id ("menu"), concatenated with "-activedescendant" to give "menu-activedescendant". This should yield unique ids fairly painlessly.
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 10:08 AM Subject: Re: jQuery UI autocomplete plugin
My guess is that AT devices are only looking for changes to the aria-activedescendant attribute. When we're changing which element has the id, that might not be something they're looking for. What happens if you change the test to move the id to the appropriate element, then remove the aria-activedescendant attribute and then immediately add it back with the same value? If that works, what happens if you just set it back to its currently value without explicitly removing it in between?
On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero <r...@mit.edu> wrote:
The little test program (at the above url) has only a single ul element with three list items beneath it. Its role is set to menu, and each li element has its role set to menuitem. The ul element has a keydown handler on it looking for up/down arrow keys. It can only be triggered when the ul item has focus. The ul item has tabindex of 0.
Jaws, and nvda, both can tab to the ul element, they call it a menu, and the key events get triggered. I'm sure the id referred to by activedescendant is valid and attached to a list item. If I press jawsKey+tab when focused on the ul element, it will read the li item with focus. When you first load the page, the third item has focus and jaws reports it as so when using jawsKey+tab.
When I arrow up or down, nothing is spoken. After pressing an arrow and I press jawsKey+tab, jaws still says the previous item with focus (item 3 if you've just loaded the page). However, if I press an arrow, tab away from the ul element, then tab back again and hit jawsKey+tab, it now reads the text of a different li - the one whose id is referenced by activedescendant.
So, where is the bug? I suspect Firefox is not sending the right stuff via the accessibility layer to the assistive technology. I suspect this since both Jaws and nvda exhibit the same seemingly incorrect behavior.
Thoughts, comments, corrections? -- Rich
----- Original Message ----- From: E.J. Zufelt To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 12:35 AM Subject: Re: jQuery UI autocomplete plugin
From what I know of active descendant, its purpose is to determine which descendant element of a compound UI component has focus, so that the developer doesn't need to handle focus within the component. For example, set focus to a menu, and then set the active descendant to the selected / active menu item. This is why it is almost certainly necessary to have focus on the compound UI component (in the case of autocomplete listbox) in order for AT to announce the change in focus / active descendant.
What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
Thoughts...? -- Rich
From: Scott González Sent: Thursday, November 11, 2010 1:21 PM To: jquery-a11y@googlegroups.com Subject: Re: jQuery UI autocomplete plugin
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 10:08 AM Subject: Re: jQuery UI autocomplete plugin
My guess is that AT devices are only looking for changes to the aria-activedescendant attribute. When we're changing which element has the id, that might not be something they're looking for. What happens if you change the test to move the id to the appropriate element, then remove the aria-activedescendant attribute and then immediately add it back with the same value? If that works, what happens if you just set it back to its currently value without explicitly removing it in between?
On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero <r...@mit.edu> wrote:
The little test program (at the above url) has only a single ul element with three list items beneath it. Its role is set to menu, and each li element has its role set to menuitem. The ul element has a keydown handler on it looking for up/down arrow keys. It can only be triggered when the ul item has focus. The ul item has tabindex of 0.
Jaws, and nvda, both can tab to the ul element, they call it a menu, and the key events get triggered. I'm sure the id referred to by activedescendant is valid and attached to a list item. If I press jawsKey+tab when focused on the ul element, it will read the li item with focus. When you first load the page, the third item has focus and jaws reports it as so when using jawsKey+tab.
When I arrow up or down, nothing is spoken. After pressing an arrow and I press jawsKey+tab, jaws still says the previous item with focus (item 3 if you've just loaded the page). However, if I press an arrow, tab away from the ul element, then tab back again and hit jawsKey+tab, it now reads the text of a different li - the one whose id is referenced by activedescendant.
So, where is the bug? I suspect Firefox is not sending the right stuff via the accessibility layer to the assistive technology. I suspect this since both Jaws and nvda exhibit the same seemingly incorrect behavior.
Thoughts, comments, corrections? -- Rich
----- Original Message ----- From: E.J. Zufelt To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 12:35 AM Subject: Re: jQuery UI autocomplete plugin
From what I know of active descendant, its purpose is to determine which descendant element of a compound UI component has focus, so that the developer doesn't need to handle focus within the component. For example, set focus to a menu, and then set the active descendant to the selected / active menu item. This is why it is almost certainly necessary to have focus on the compound UI component (in the case of autocomplete listbox) in order for AT to announce the change in focus / active descendant.
What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
Thoughts...? -- Rich
From: Scott González Sent: Thursday, November 11, 2010 1:21 PM To: jquery-a11y@googlegroups.com Subject: Re: jQuery UI autocomplete plugin
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
Okay, so we've got a fix for the menu bug. When creating a menu, we'll check if it has an id. If it doesn't, we'll generate a unique id (maybe menu-X where X increments for every menu). When selecting a menu item, we'll check if it has an id. If it doesn't, we'll assign the menu's id concatenated with "-activedescendant". We'll always remove and reset the aria-activedescenant attribute on the menu when changing which item is selected.
Now we need to figure out how to deal with the autocomplete situation where we want to keep focus on the text field.
On Fri, Nov 12, 2010 at 5:20 PM, Rich Caloggero <rich_calogg...@wgbh.org>wrote:
> OK, I've got it to work. It was your suggestion Scott which fixed the > problem. The steps you must follow are: > 1. remove the aria-activedescendant attribute altogether from the > container; > 2. move your chosen id string from the old menu item to the new one; > 3. add the aria-activedescendant attribute back to the container, referring > to the chosen id string.
> I've used the convention that the chosen activedescendant id for this > container is the container id ("menu"), concatenated with > "-activedescendant" to give "menu-activedescendant". This should yield > unique ids fairly painlessly.
> -- Rich
> ----- Original Message ----- > *From:* Scott González <scott.gonza...@gmail.com> > *To:* jquery-a11y@googlegroups.com > *Sent:* Friday, November 12, 2010 10:08 AM > *Subject:* Re: jQuery UI autocomplete plugin
> My guess is that AT devices are only looking for changes to the > aria-activedescendant attribute. When we're changing which element has the > id, that might not be something they're looking for. What happens if you > change the test to move the id to the appropriate element, then remove the > aria-activedescendant attribute and then immediately add it back with the > same value? If that works, what happens if you just set it back to its > currently value without explicitly removing it in between?
> On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero <r...@mit.edu> wrote:
>> The little test program (at the above url) has only a single ul element >> with three list items beneath it. Its role is set to menu, and each li >> element has its role set to menuitem. The ul element has a keydown handler >> on it looking for up/down arrow keys. It can only be triggered when the ul >> item has focus. The ul item has tabindex of 0.
>> Jaws, and nvda, both can tab to the ul element, they call it a menu, and >> the key events get triggered. I'm sure the id referred to by >> activedescendant is valid and attached to a list item. If I press >> jawsKey+tab when focused on the ul element, it will read the li item with >> focus. When you first load the page, the third item has focus and jaws >> reports it as so when using jawsKey+tab.
>> When I arrow up or down, nothing is spoken. After pressing an arrow and I >> press jawsKey+tab, jaws still says the previous item with focus (item 3 if >> you've just loaded the page). However, if I press an arrow, tab away from >> the ul element, then tab back again and hit jawsKey+tab, it now reads the >> text of a different li - the one whose id is referenced by activedescendant.
>> So, where is the bug? I suspect Firefox is not sending the right stuff via >> the accessibility layer to the assistive technology. I suspect this since >> both Jaws and nvda exhibit the same seemingly incorrect behavior.
>> Thoughts, comments, corrections? >> -- Rich
>> ----- Original Message ----- >> *From:* E.J. Zufelt <li...@zufelt.ca> >> *To:* jquery-a11y@googlegroups.com >> *Sent:* Friday, November 12, 2010 12:35 AM >> *Subject:* Re: jQuery UI autocomplete plugin
>> From what I know of active descendant, its purpose is to determine which >> descendant element of a compound UI component has focus, so that the >> developer doesn't need to handle focus within the component. For example, >> set focus to a menu, and then set the active descendant to the selected / >> active menu item. This is why it is almost certainly necessary to have >> focus on the compound UI component (in the case of autocomplete listbox) in >> order for AT to announce the change in focus / active descendant.
>> What happens is that when you focus on the menu (second tabstop on the >> page), you hear jaws announce the menu item with the id that >> aria-activedescendant references. However, when you change the item to >> which aria-activedescendant references, jaws (and nvda) do not announce the >> new state until you tab away from the element and then back again. You can >> verify this using this test case. >> Uncommenting the last alert in the handler shows that the correct item is >> being chosen, and Jaws does report it when you tab away and back again.
>> Its odd that both jaws and nvda have this behavior. Seems like a bug, but >> perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
>> On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
>>> Another thought, I am writing quickly so I haven't looked back at the >>> code.
>>> If I recall correctly the autocomplete isn't actually changing the active >>> descendant. It is, in the fact that it is changing the listitem that has >>> the active descendant id, but it isn't actually changing the value of the >>> active descendant property itself. This might mean that UAs aren't firing >>> the correct events to have the change tracked.
>> We should verify whether the current model works in a simplified test >> case.
>>> Also, if I recall, there is no way to specify a prefix to the ids for >>> the widget, meaning possibly that the widget can only be used once per >>> page. This would probably make it difficult to use in a system like Drupal >>> where it may need to appear multiple times on the same page. Perhaps there >>> is a way to do this currently that I am missing.
>> This is a known limitation that needs to be fixed in the menu widget that >> autocomplete is using. >> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "jQuery Accessibility" group. >> To post to this group, send email to jquery-a11y@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "jQuery Accessibility" group. > To post to this group, send email to jquery-a11y@googlegroups.com. > To unsubscribe from this group, send email to > jquery-a11y+unsubscribe@googlegroups.com<jquery-a11y%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-a11y?hl=en.
The only solution I've found is to put aria-live="assertive" on the menu and then rewrite the new child element (the one which will be receiving focus). aria-owns and/or aria-controls didn't seem to do anything in both jaws and nvda.
This is also the solution I've used to make jquery-ui dialogs speak correctly. The aria-alertdialog role is supposed to do this, but it does not work in either screen reader. I suspect there is a timing issue here since the dialog is unhidden just before it is shown. The container holding the live region attributes must be visible when the change to any of its children happens. The way around it is to rewrite the text of the dialog when we're sure the dialog container is fully visible; I do this in the dialogopen event handler.
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 5:34 PM Subject: Re: jQuery UI autocomplete plugin
Okay, so we've got a fix for the menu bug. When creating a menu, we'll check if it has an id. If it doesn't, we'll generate a unique id (maybe menu-X where X increments for every menu). When selecting a menu item, we'll check if it has an id. If it doesn't, we'll assign the menu's id concatenated with "-activedescendant". We'll always remove and reset the aria-activedescenant attribute on the menu when changing which item is selected.
Now we need to figure out how to deal with the autocomplete situation where we want to keep focus on the text field.
On Fri, Nov 12, 2010 at 5:20 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
OK, I've got it to work. It was your suggestion Scott which fixed the problem. The steps you must follow are: 1. remove the aria-activedescendant attribute altogether from the container; 2. move your chosen id string from the old menu item to the new one; 3. add the aria-activedescendant attribute back to the container, referring to the chosen id string.
I've used the convention that the chosen activedescendant id for this container is the container id ("menu"), concatenated with "-activedescendant" to give "menu-activedescendant". This should yield unique ids fairly painlessly.
-- Rich
----- Original Message ----- From: Scott González To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 10:08 AM Subject: Re: jQuery UI autocomplete plugin
My guess is that AT devices are only looking for changes to the aria-activedescendant attribute. When we're changing which element has the id, that might not be something they're looking for. What happens if you change the test to move the id to the appropriate element, then remove the aria-activedescendant attribute and then immediately add it back with the same value? If that works, what happens if you just set it back to its currently value without explicitly removing it in between?
On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero <r...@mit.edu> wrote:
The little test program (at the above url) has only a single ul element with three list items beneath it. Its role is set to menu, and each li element has its role set to menuitem. The ul element has a keydown handler on it looking for up/down arrow keys. It can only be triggered when the ul item has focus. The ul item has tabindex of 0.
Jaws, and nvda, both can tab to the ul element, they call it a menu, and the key events get triggered. I'm sure the id referred to by activedescendant is valid and attached to a list item. If I press jawsKey+tab when focused on the ul element, it will read the li item with focus. When you first load the page, the third item has focus and jaws reports it as so when using jawsKey+tab.
When I arrow up or down, nothing is spoken. After pressing an arrow and I press jawsKey+tab, jaws still says the previous item with focus (item 3 if you've just loaded the page). However, if I press an arrow, tab away from the ul element, then tab back again and hit jawsKey+tab, it now reads the text of a different li - the one whose id is referenced by activedescendant.
So, where is the bug? I suspect Firefox is not sending the right stuff via the accessibility layer to the assistive technology. I suspect this since both Jaws and nvda exhibit the same seemingly incorrect behavior.
Thoughts, comments, corrections? -- Rich
----- Original Message ----- From: E.J. Zufelt To: jquery-a11y@googlegroups.com Sent: Friday, November 12, 2010 12:35 AM Subject: Re: jQuery UI autocomplete plugin
From what I know of active descendant, its purpose is to determine which descendant element of a compound UI component has focus, so that the developer doesn't need to handle focus within the component. For example, set focus to a menu, and then set the active descendant to the selected / active menu item. This is why it is almost certainly necessary to have focus on the compound UI component (in the case of autocomplete listbox) in order for AT to announce the change in focus / active descendant.
What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
Thoughts...? -- Rich
From: Scott González Sent: Thursday, November 11, 2010 1:21 PM To: jquery-a11y@googlegroups.com Subject: Re: jQuery UI autocomplete plugin
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to
The only solution I've found is to put aria-live="assertive" on the menu and then rewrite the new child element (the one which will be receiving focus). aria-owns and/or aria-controls didn't seem to do anything in both jaws and nvda.
This is also the solution I've used to make jquery-ui dialogs speak correctly. The aria-alertdialog role is supposed to do this, but it does not work in either screen reader. I suspect there is a timing issue here since the dialog is unhidden just before it is shown. The container holding the live region attributes must be visible when the change to any of its children happens. The way around it is to rewrite the text of the dialog when we're sure the dialog container is fully visible; I do this in the dialogopen event handler.
Okay, so we've got a fix for the menu bug. When creating a menu, we'll check if it has an id. If it doesn't, we'll generate a unique id (maybe menu-X where X increments for every menu). When selecting a menu item, we'll check if it has an id. If it doesn't, we'll assign the menu's id concatenated with "-activedescendant". We'll always remove and reset the aria-activedescenant attribute on the menu when changing which item is selected.
Now we need to figure out how to deal with the autocomplete situation where we want to keep focus on the text field.
On Fri, Nov 12, 2010 at 5:20 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
OK, I've got it to work. It was your suggestion Scott which fixed the problem. The steps you must follow are: 1. remove the aria-activedescendant attribute altogether from the container; 2. move your chosen id string from the old menu item to the new one; 3. add the aria-activedescendant attribute back to the container, referring to the chosen id string.
I've used the convention that the chosen activedescendant id for this container is the container id ("menu"), concatenated with "-activedescendant" to give "menu-activedescendant". This should yield unique ids fairly painlessly.
-- Rich
----- Original Message ----- From: Scott González
To: jquery-a11y@googlegroups.com
Sent: Friday, November 12, 2010 10:08 AM Subject: Re: jQuery UI autocomplete plugin
My guess is that AT devices are only looking for changes to the aria-activedescendant attribute. When we're changing which element has the id, that might not be something they're looking for. What happens if you change the test to move the id to the appropriate element, then remove the aria-activedescendant attribute and then immediately add it back with the same value? If that works, what happens if you just set it back to its currently value without explicitly removing it in between?
On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero <r...@mit.edu> wrote:
The little test program (at the above url) has only a single ul element with three list items beneath it. Its role is set to menu, and each li element has its role set to menuitem. The ul element has a keydown handler on it looking for up/down arrow keys. It can only be triggered when the ul item has focus. The ul item has tabindex of 0.
Jaws, and nvda, both can tab to the ul element, they call it a menu, and the key events get triggered. I'm sure the id referred to by activedescendant is valid and attached to a list item. If I press jawsKey+tab when focused on the ul element, it will read the li item with focus. When you first load the page, the third item has focus and jaws reports it as so when using jawsKey+tab.
When I arrow up or down, nothing is spoken. After pressing an arrow and I press jawsKey+tab, jaws still says the previous item with focus (item 3 if you've just loaded the page). However, if I press an arrow, tab away from the ul element, then tab back again and hit jawsKey+tab, it now reads the text of a different li - the one whose id is referenced by activedescendant.
So, where is the bug? I suspect Firefox is not sending the right stuff via the accessibility layer to the assistive technology. I suspect this since both Jaws and nvda exhibit the same seemingly incorrect behavior.
Thoughts, comments, corrections? -- Rich
----- Original Message ----- From: E.J. Zufelt To: jquery-a11y@googlegroups.com
Sent: Friday, November 12, 2010 12:35 AM Subject: Re: jQuery UI autocomplete plugin
From what I know of active descendant, its purpose is to determine which descendant element of a compound UI component has focus, so that the developer doesn't need to handle focus within the component. For example, set focus to a menu, and then set the active descendant to the selected / active menu item. This is why it is almost certainly necessary to have focus on the compound UI component (in the case of autocomplete listbox) in order for AT to announce the change in focus / active descendant.
What happens is that when you focus on the menu (second tabstop on the page), you hear jaws announce the menu item with the id that aria-activedescendant references. However, when you change the item to which aria-activedescendant references, jaws (and nvda) do not announce the new state until you tab away from the element and then back again. You can verify this using this test case. Uncommenting the last alert in the handler shows that the correct item is being chosen, and Jaws does report it when you tab away and back again.
Its odd that both jaws and nvda have this behavior. Seems like a bug, but perhaps I’m misunderstanding how aria-activedescendant is supposed to work?
Thoughts...? -- Rich
From: Scott González Sent: Thursday, November 11, 2010 1:21 PM To: jquery-a11y@googlegroups.com Subject: Re: jQuery UI autocomplete plugin
On Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
Another thought, I am writing quickly so I haven't looked back at the code.
If I recall correctly the autocomplete isn't actually changing the active descendant. It is, in the fact that it is changing the listitem that has the active descendant id, but it isn't actually changing the value of the active descendant property itself. This might mean that UAs aren't firing the correct events to have the change tracked.
We should verify whether the current model works in a simplified test case.
Also, if I recall, there is no way to specify a prefix to the ids for the widget, meaning possibly that the widget can only be used once per page. This would probably make it difficult to use in a system like Drupal where it may need to appear multiple times on the same page. Perhaps there is a way to do this currently that I am missing.
This is a known limitation that needs to be fixed in the menu widget that autocomplete is using. -- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.
-- You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group. To post to this group, send email to jquery-a11y@googlegroups.com. To unsubscribe from this group,
I tested the demo of the menu. JAWS 11 / FF 3.6 reports this as a listbox, not as a menu. It doesn't appear to have a title at all (JAWS just reads "listbox"). It also doesn't appear to have any content.
I imagine that with some more work and experimentation we can get this working properly, I don't think that using aria-live is the proper way to do this.
> The only solution I've found is to put aria-live="assertive" on the menu > and then rewrite the new child element (the one which will be receiving > focus). > aria-owns and/or aria-controls didn't seem to do anything in both jaws and > nvda.
> This is also the solution I've used to make jquery-ui dialogs speak > correctly. The aria-alertdialog role is supposed to do this, but it does not > work in either screen reader. I suspect there is a timing issue here since the > dialog is unhidden just before it is shown. The container holding the live > region attributes must be visible when the change to any of its children > happens. The way around it is to rewrite the text of the dialog when we're sure > the dialog container is fully visible; I do this in the dialogopen event > handler.
> Okay, so we've got a fix for the menu bug. > When creating a menu, we'll check if it has an id. If it doesn't, we'll > generate a unique id (maybe menu-X where X increments for every menu). When > selecting a menu item, we'll check if it has an id. If it doesn't, we'll > assign the menu's id concatenated with "-activedescendant". We'll always > remove and reset the aria-activedescenant attribute on the menu when changing > which item is selected.
> Now we need to figure out how to deal with the > autocomplete situation where we want to keep focus on the text > field.
> On Fri, Nov 12, 2010 at 5:20 PM, Rich Caloggero <rich_calogg...@wgbh.org> > wrote:
> OK, I've got it to work. It was your suggestion > Scott which fixed the problem. The steps you must follow are: > 1. remove the aria-activedescendant attribute > altogether from the container; > 2. move your chosen id string from the old menu > item to the new one; > 3. add the aria-activedescendant attribute back > to the container, referring to the chosen id string.
> I've used the convention that the chosen > activedescendant id for this container is the container id ("menu"), > concatenated with "-activedescendant" to give "menu-activedescendant". > This should yield unique ids fairly painlessly.
> -- Rich
> ----- Original Message ----- > From: > Scott González
> To: jquery-a11y@googlegroups.com
> Sent: Friday, November 12, 2010 10:08 > AM > Subject: Re: jQuery UI autocomplete > plugin
> My guess is that AT devices are only looking for changes to > the aria-activedescendant attribute. When we're changing which > element has > the id, that might not be something they're looking for. What happens if > you change the test to move the id to the appropriate element, > then remove > the aria-activedescendant attribute and then immediately add it back with > the same value? If that works, what happens if you just set it > back to its > currently value without explicitly removing it in between?
> On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero > <r...@mit.edu> wrote:
> The little test program (at the above url) has only a > single ul element with three list items beneath it. Its role is set to > menu, and each li element has its role set to menuitem. The ul > element has a keydown handler on it looking for up/down arrow > keys. It can only be triggered when the ul item has focus. The ul > item has tabindex of 0.
> Jaws, and nvda, both can tab to the ul element, they > call it a menu, and the key events get triggered. I'm sure the id > referred to by activedescendant is valid and attached to a list > item. If I press jawsKey+tab when focused on the ul element, it > will read the li item with focus. When you first load the page, the > third item has focus and jaws reports it as so when using jawsKey+tab.
> When I arrow up or down, nothing is spoken. > After pressing an arrow and I press jawsKey+tab, jaws still says the > previous item with focus (item 3 if you've just loaded the page). > However, if I press an arrow, tab away from the ul element, then tab > back again and hit jawsKey+tab, it now reads the text of a different li > - the one whose id is referenced by activedescendant.
> So, where is the bug? I suspect Firefox is not sending > the right stuff via the accessibility layer to the assistive > technology. > I suspect this since both Jaws and nvda exhibit the same seemingly > incorrect behavior.
> Thoughts, comments, corrections? > -- Rich
> ----- Original Message ----- > From: E.J. > Zufelt > To: jquery-a11y@googlegroups.com
> Sent: Friday, November 12, 2010 > 12:35 AM > Subject: Re: jQuery UI > autocomplete plugin
> From what I know of active descendant, its purpose is > to determine which descendant element of a compound UI component has > focus, so that the developer doesn't need to handle focus within the > component. For example, set focus to a menu, and then set the > active descendant to the selected / active menu item. This is > why it is almost certainly necessary to have focus on the compound UI > component (in the case of autocomplete listbox) in order for AT to > announce the change in focus / active descendant.
> What happens is that when you focus on the menu (second tabstop > on the page), you hear jaws announce the menu item with the id that > aria-activedescendant references. However, when you change the > item to which aria-activedescendant references, jaws (and nvda) do > not announce the new state until you tab away from the element and > then back again. You can verify this using this test case. > Uncommenting the last alert in the handler shows that the > correct item is being chosen, and Jaws does report it when you tab > away and back again.
> Its odd that both jaws and nvda have this behavior. Seems like > a bug, but perhaps I’m misunderstanding how > aria-activedescendant is > supposed to work?
> Thoughts...? > -- Rich
> From: Scott > González > Sent: Thursday, November 11, 2010 1:21 PM > To: jquery-a11y@googlegroups.com > Subject: Re: jQuery UI autocomplete > plugin
> On > Thu, Nov 11, 2010 at 1:17 PM, E.J. Zufelt <ever...@zufelt.ca> wrote:
> Another thought, I am writing > quickly so I haven't looked back at the code.
> If I recall correctly the autocomplete isn't actually > changing the active descendant. It is, in the fact that it > is changing the listitem that has the active descendant > id, but it > isn't actually changing the value of the active descendant > property itself. This might mean that UAs aren't firing the > correct events to have the change tracked.
> We should verify whether the current model works in a > simplified test case.
> Also, if I recall, there is no way to specify a prefix to the > ids for the widget, meaning possibly that the widget can only be > used once per page. This would probably make it difficult to > use in a system like Drupal where it may need to appear multiple > times on the same page. Perhaps there is a way to do this > currently that I am missing.
> This is a known limitation that needs to be fixed in the > menu widget that autocomplete is using. > -- > You > received this message because you are subscribed to the Google > Groups
I've got something working, but its not perfect and it relies on live regions. I'm using autocomplete events, but similar techniques should be rolled into the autocomplete source. I could be missing something entirely, but I don't see any other way at present to cause the screen reader to read the menu when focus is elsewhere (i.e. on the input element). Live regions were invented to solve just this type of problem. It seems like aria-owns could be useful here, but it doesn't seem to do anything that I can see. aria-activedescendant only works when focus is actually in the menu.
Goto the above url, focus on the input field, then just press downarrow. The first time, jaws will just say "edit", but the menu does open. The next press of downArrow begins reading the menu. Pressing enter after hearing a menu item read will copy that text into the input field and add a comman and space to the end of the string, then wait for more key presses. The menu is closed. More presses of the downArrow will open another menu and then subsequent presses will begin reading it.
If you type alphabetic characters (try j followed by a), nothing is spoken, but you can browse the matches by using downArrow again. The menu opens when the first character is typed.
Here's the basic idea of my solution:
In the open event callback we add aria-live to the menu container and set it to off. If we turn it on at this point, we get all sorts of extra chatter, which I assume is generated when bits of the menu are scrolled. In the focus event callback, I turn on the live region and rewrite the active menu item, which triggers the live region. However, there is a timing issue which prevents the first attempted triggering of the live region to fail. The problem is that we add the live region attribute in the open callback, and we attempt to trigger it when the focus event is called, which is too soon after the attribute is added. It takes almost 250 milliseconds for the browser and screen reader to realize that a live region has been defined. All subsequent focus event callbacks do trigger the live region.
I'd also like the screen reader to tell me how many items are in the menu. I tried to hack this by creating a hidden div (using css clip to make it invisible, but leave it in the dom so the screen reader will see it). However, I've never gotten this to work.
I use role="application" on the div containing the input element. This keeps focus on the field, event when up/down arrows are pressed. Normally, jaws will move you out of an input text field when arrows are pressed. Actually, in firefox, this is only true if "remember form history" is turned off in the privacy section of the firefox options dialog.
The menu is identified as a listbox because in a previous version (jquery-ui 1.8.4 I believe), I was reviewing autocomplete for a client and found that if we made the menu a listbox, jaws would pay attention and track things via aria-activedescendant. This worked (and continues to work) for all cases except this multiple values demo. From what Scott said in previous messages in this thread, this is most likely because in all other cases, focus stays in the menu when it appears. In the multiple values case, focus is always returned to the input element via a value of false returned from the autocomplete's focus callback.
----- Original Message ----- From: E.J. Zufelt To: jquery-a11y@googlegroups.com Sent: Saturday, November 20, 2010 3:36 AM Subject: Re: jQuery UI autocomplete plugin
I tested the demo of the menu. JAWS 11 / FF 3.6 reports this as a listbox, not as a menu. It doesn't appear to have a title at all (JAWS just reads "listbox"). It also doesn't appear to have any content.
I imagine that with some more work and experimentation we can get this working properly, I don't think that using aria-live is the proper way to do this.
The only solution I've found is to put aria-live="assertive" on the menu and then rewrite the new child element (the one which will be receiving focus). aria-owns and/or aria-controls didn't seem to do anything in both jaws and nvda.
This is also the solution I've used to make jquery-ui dialogs speak correctly. The aria-alertdialog role is supposed to do this, but it does not work in either screen reader. I suspect there is a timing issue here since the dialog is unhidden just before it is shown. The container holding the live region attributes must be visible when the change to any of its children happens. The way around it is to rewrite the text of the dialog when we're sure the dialog container is fully visible; I do this in the dialogopen event handler.
Okay, so we've got a fix for the menu bug. When creating a menu, we'll check if it has an id. If it doesn't, we'll generate a unique id (maybe menu-X where X increments for every menu). When selecting a menu item, we'll check if it has an id. If it doesn't, we'll assign the menu's id concatenated with "-activedescendant". We'll always remove and reset the aria-activedescenant attribute on the menu when changing which item is selected.
Now we need to figure out how to deal with the autocomplete situation where we want to keep focus on the text field.
On Fri, Nov 12, 2010 at 5:20 PM, Rich Caloggero <rich_calogg...@wgbh.org> wrote:
OK, I've got it to work. It was your suggestion Scott which fixed the problem. The steps you must follow are: 1. remove the aria-activedescendant attribute altogether from the container; 2. move your chosen id string from the old menu item to the new one; 3. add the aria-activedescendant attribute back to the container, referring to the chosen id string.
I've used the convention that the chosen activedescendant id for this container is the container id ("menu"), concatenated with "-activedescendant" to give "menu-activedescendant". This should yield unique ids fairly painlessly.
-- Rich
----- Original Message ----- From: Scott González
To: jquery-a11y@googlegroups.com
Sent: Friday, November 12, 2010 10:08 AM Subject: Re: jQuery UI autocomplete plugin
My guess is that AT devices are only looking for changes to the aria-activedescendant attribute. When we're changing which element has the id, that might not be something they're looking for. What happens if you change the test to move the id to the appropriate element, then remove the aria-activedescendant attribute and then immediately add it back with the same value? If that works, what happens if you just set it back to its currently value without explicitly removing it in between?
On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero <r...@mit.edu> wrote:
The little test program (at the above url) has only a single ul element with three list items beneath it. Its role is set to menu, and each li element has its role set to menuitem. The ul element has a keydown handler on it looking for up/down arrow keys. It can only be triggered when the ul item has focus. The ul item has tabindex of 0.
Jaws, and nvda, both can tab to the ul element, they call it a menu, and the key events get triggered. I'm sure the id referred to by activedescendant is valid and attached to a list item. If I press jawsKey+tab when focused on the ul element, it will read the li item with focus. When you first load the page, the third item has focus and jaws reports it as so when using jawsKey+tab.
When I arrow up or down, nothing is spoken. After pressing an arrow and I press jawsKey+tab, jaws still says the previous item with focus (item 3 if you've just loaded the page). However, if I press an arrow, tab away from the ul element, then tab back again and hit jawsKey+tab, it now reads the text of a different li - the one whose id is referenced by activedescendant.
So, where is the bug? I suspect Firefox is not sending the right stuff via the accessibility layer to the assistive technology. I suspect this since both Jaws and nvda exhibit the same seemingly incorrect behavior.
> I've got something working, but its not perfect and it relies on live > regions. I'm using autocomplete events, but similar techniques should be > rolled into the autocomplete source. > I could be missing something entirely, but I don't see any other way at > present to cause the screen reader to read the menu when focus is elsewhere > (i.e. on the input element). Live regions were invented to solve just this > type of problem. It seems like aria-owns could be useful here, but it > doesn't seem to do anything that I can see. aria-activedescendant only > works when focus is actually in the menu.
> Goto the above url, focus on the input field, then just press downarrow. > The first time, jaws will just say "edit", but the menu does open. The next > press of downArrow begins reading the menu. Pressing enter after hearing a > menu item read will copy that text into the input field and add a comman and > space to the end of the string, then wait for more key presses. The menu is > closed. More presses of the downArrow will open another menu and then > subsequent presses will begin reading it.
> If you type alphabetic characters (try j followed by a), nothing is spoken, > but you can browse the matches by using downArrow again. The menu opens when > the first character is typed.
> Here's the basic idea of my solution:
> In the open event callback we add aria-live to the menu container and set > it to off. If we turn it on at this point, we get all sorts of extra > chatter, which I assume is generated when bits of the menu are scrolled. In > the focus event callback, I turn on the live region and rewrite the active > menu item, which triggers the live region. However, there is a timing issue > which prevents the first attempted triggering of the live region to fail. > The problem is that we add the live region attribute in the open callback, > and we attempt to trigger it when the focus event is called, which is too > soon after the attribute is added. It takes almost 250 milliseconds for the > browser and screen reader to realize that a live region has been defined. > All subsequent focus event callbacks do trigger the live region.
> I'd also like the screen reader to tell me how many items are in the menu. > I tried to hack this by creating a hidden div (using css clip to make it > invisible, but leave it in the dom so the screen reader will see it). > However, I've never gotten this to work.
> I use role="application" on the div containing the input element. This > keeps focus on the field, event when up/down arrows are pressed. Normally, > jaws will move you out of an input text field when arrows are pressed. > Actually, in firefox, this is only true if "remember form history" is turned > off in the privacy section of the firefox options dialog.
> The menu is identified as a listbox because in a previous version > (jquery-ui 1.8.4 I believe), I was reviewing autocomplete for a client and > found that if we made the menu a listbox, jaws would pay attention and track > things via aria-activedescendant. This worked (and continues to work) for > all cases except this multiple values demo. From what Scott said in > previous messages in this thread, this is most likely because in all other > cases, focus stays in the menu when it appears. In the multiple values case, > focus is always returned to the input element via a value of false returned > from the autocomplete's focus callback.
> -- Rich
> ----- Original Message ----- > *From:* E.J. Zufelt <li...@zufelt.ca> > *To:* jquery-a11y@googlegroups.com > *Sent:* Saturday, November 20, 2010 3:36 AM > *Subject:* Re: jQuery UI autocomplete plugin
> I tested the demo of the menu. JAWS 11 / FF 3.6 reports this as a listbox, > not as a menu. It doesn't appear to have a title at all (JAWS just reads > "listbox"). It also doesn't appear to have any content.
> I imagine that with some more work and experimentation we can get this > working properly, I don't think that using aria-live is the proper way to do > this.
> The only solution I've found is to put aria-live="assertive" on the menu > and then rewrite the new child element (the one which will be receiving > focus). > aria-owns and/or aria-controls didn't seem to do anything in both jaws and > nvda.
> This is also the solution I've used to make jquery-ui dialogs speak > correctly. The aria-alertdialog role is supposed to do this, but it does > not > work in either screen reader. I suspect there is a timing issue here since > the > dialog is unhidden just before it is shown. The container holding the live > region attributes must be visible when the change to any of its children > happens. The way around it is to rewrite the text of the dialog when we're > sure > the dialog container is fully visible; I do this in the dialogopen event > handler.
> Okay, so we've got a fix for the menu bug. > When creating a menu, we'll check if it has an id. If it doesn't, we'll > generate a unique id (maybe menu-X where X increments for every menu). > When > selecting a menu item, we'll check if it has an id. If it doesn't, we'll > assign the menu's id concatenated with "-activedescendant". We'll always > remove and reset the aria-activedescenant attribute on the menu when > changing > which item is selected.
> Now we need to figure out how to deal with the > autocomplete situation where we want to keep focus on the text > field.
> On Fri, Nov 12, 2010 at 5:20 PM, Rich Caloggero <rich_calogg...@wgbh.org> > wrote:
> OK, I've got it to work. It was your suggestion > Scott which fixed the problem. The steps you must follow are: > 1. remove the aria-activedescendant attribute > altogether from the container; > 2. move your chosen id string from the old menu > item to the new one; > 3. add the aria-activedescendant attribute back > to the container, referring to the chosen id string.
> I've used the convention that the chosen > activedescendant id for this container is the container id ("menu"), > concatenated with "-activedescendant" to give "menu-activedescendant". > This should yield unique ids fairly painlessly.
> -- Rich
> ----- Original Message ----- > From: > Scott González
> To: jquery-a11y@googlegroups.com
> Sent: Friday, November 12, 2010 10:08 > AM > Subject: Re: jQuery UI autocomplete > plugin
> My guess is that AT devices are only looking for changes to > the aria-activedescendant attribute. When we're changing which > element has > the id, that might not be something they're looking for. What happens > if > you change the test to move the id to the appropriate element, > then remove > the aria-activedescendant attribute and then immediately add it back > with > the same value? If that works, what happens if you just set it > back to its > currently value without explicitly removing it in between?
> On Fri, Nov 12, 2010 at 10:00 AM, Rich Caloggero > <r...@mit.edu> wrote:
> The little test program (at the above url) has only a > single ul element with three list items beneath it. Its role is set > to > menu, and each li element has its role set to menuitem. The ul > element has a keydown handler on it looking for up/down arrow > keys. It can only be triggered when the ul item has focus. The ul > item has tabindex of 0.
> Jaws, and nvda, both can tab to the ul element, they > call it a menu, and the key events get triggered. I'm sure the id > referred to by activedescendant is valid and attached to a list > item. If I press jawsKey+tab when focused on the ul element, it > will read the li item with focus. When you first load the page, the > third item has focus and jaws reports it as so when using > jawsKey+tab.
> When I arrow up or down, nothing is spoken. > After pressing an arrow and I press jawsKey+tab, jaws still says the > previous item with focus (item 3 if you've just loaded the page). > However, if I press an arrow, tab away from the ul element, then tab > back again and hit jawsKey+tab, it now reads the text of a different > li > - the one whose id is referenced by activedescendant.
> So, where is the bug? I suspect Firefox is not sending > the right stuff via the accessibility layer to the assistive > technology. > I suspect this since both Jaws and nvda exhibit the same seemingly > incorrect behavior.
