Im making an FTP client, which will rely a lot on javascript.
When browsing through the files, you can navigate using the arrow keys. I add a class of .selected to the currently selected filename, but how can I make this clear to screenreaders? How do I make them focus on the current filename?
Would the best way be to make every filename an anchor, which will get the focus when the filename is selected? And also, where can I find a good guide on web application accessibility? I know the W3C has a checklist for content accessibility, but most of the points there don't apply to web apps.
Simplest way to do this is perhaps to have a series of checkboxes, each with a unique ID, paired with a label:
<input id="chk01" type="checkbox"/><label for="chk01">File1.txt</label>
Using this technique, the input is doing the work of exposing a selected-ness for you, while the label takes care of associating it with the name: when focus goes to the checkbox, the screenreader will automatically read out the associated label text. It's all plain HTML, nothing special required. You're free of course to add in selection coloring on top of this - so long as you keep it in sync with checkbox state.
It may be possible to do something similar with A tags; you can use WAI-ARIA properties to set role="listitem" and aria-selected="true"/"false" as appropriate on the items, with role="list" on the parent container. A screenreader will then read these out as list items, rather than links. This technique is more involved, however, and would really need to be tested with an actual screen reader (eg JAWS, or the freely-available NVDA) to ensure it works.
I would suggest you use a javascript framework to help with accessibility in conjunction with WAI-ARIA For examples of accessible jQuery see
https://github.com/fnagel/jQuery-Accessible-RIA/wiki and for examples of accessible drag and drop with WAI-ARIA see
http://dev.opera.com/articles/view/accessible-drag-and-drop/
First - make sure your basics are covered. The Web Content Accessibility Guidelines (WCAG) don't cover interactivity well, but many of its points remain applicable to web applications.
Next - learn about the ARIA standard for Accessible Rich Internet Applications. This will cover a lot of the interactivity you're trying for.
Some relevant links:
http://webaim.org/ for common accessibility problems, plus some invaluable surveys of screen reader usage
http://www.w3.org/WAI/intro/wcag.php - overview of WCAG 2.0
http://www.w3.org/WAI/intro/aria.php - overview of ARIA
There are a number of books on accessibility, which tend to get outdated fairly fast. Sadly, I'm not aware of any book-length discussions of ARIA -- it's still in development. Try reading the specs.
Last but not least -- get a screen reader and learn to use it. Formal compliance with accessibility standards is great, but nothing beats real testing. NVDA is a free and fully featured screen reader that has decent support for ARIA: http://nvda-project.org/
Hope this helps.
When browsing through the files, you can navigate using the arrow keys.
Building upon a previous answer that neglected this feature, wrap the entire widget in a div with role=application. This notifies the screen reader that JavaScript will be used and will allow the user to navigate the widget with the arrow keys while using a screen reader. The excerpt below details how to design the widget to be accessible. Yes, it's not the simplest solution, but it is the most complete. Take your pick.
Description: A widget that allows the user to select one or more items from a list of choices. (listbox). Keyboard Interaction: Tab: When a list is tabbed to, select the first item if nothing else is already selected. A second tab will take the user out of the widget to the next tab stop on the page. Up/down arrows navigate up and down the list. Shift+Up Arrow and Shift+Down Arrow move and extend the selection. Typing letter or several letters to navigate (same letter goes to each item starting with that, different letters go to first item starting with that entire string). Shift+F10: If the current item has an associated context menu, then this key combination will launch that menu. Selection
Checkbox - Space toggles checkboxes, if the list items are checkable Selectable List Items
Space acts as a toggle to select and deselect the current item. If previous items have been selected, it also deselects them and selects the current item. Shift+Space selects contiguous items from the last selected item to the current item. Ctrl+Arrow moves without selecting. Ctrl+Space selects non-contiguous items and adds the current selected item to all previously selected items. Ctrl+A - It is recommended a checkbox, link or other method be used to select all. The Ctrl+A key could be used to provide the shortcut key.
It is recommended the developer use different styling for the selection when the list is not focused (hint: non-active selection is often shown with a lighter background color). WAI-ARIA Roles, States, and Properties: The listbox container has a role of listbox.Each entry in the listbox should have a role option and should be DOM children of listbox.If is not a DOM child of listbox, then it should be referenced in the listbox by aria-owns.If all items in the listbox are not DOM children of the listbox, then set their aria-setsize and aria-posinset accordingly; otherwise, this information cannot be computed for context by the user agent.If the listbox is not part of another widget, then it should have a visible aria-label referenced on the listbox by
aria-labelledby.Each selected list item should have aria-selected="true".
Examples:
Single select listbox
Listbox in an iframe
Refer to the authoring practices for accessible widgets for examples and more information.
From what I understand, YUI has a large amount of support for ARIA.
See:
http://developer.yahoo.com/yui/theater/video.php?v=kloots-yuiconf2009-a11y
Make sure your solution conforms to ARIA:
http://www.w3.org/WAI/intro/aria.php
HTH
Related
I'm working on a chat web application. I want to make sure it is accessible for everyone. Currently, when I tab to the chat content, the focus goes to the first message in the chat - which is at the top of the screen. To access the most recent messages, the user must tab through all the messages. Is there a way to override this behavior so tabbing starts at the bottom of the screen? I can't modify the order of elements in the DOM because that will display the messages out of order and confuse users who don't use a screenreader. Besides, the user would still need to tab through all of the messages to access the input to send a message. How can I make sure tabbing doesn't scroll to the top of the screen?
Bad answer
You could use positive tabindex values, but it's a bad practice.
Many explanations exist about why it's bad. Don't use tabindex.
Simple answer
People who frequently use tab to navigate usually also know that they can move backwards with shift+tab.
So you are safe if you do nothing special, and just assume they will be smart enough to navigate backwards in order to quickly reach last messages.
Better answer
Ask yourself this question: do each messages really has to be individually focusable ?
Probably the answer is no, or at least not so directly with tab alone.
For your particular case, I suggest you to make a list box instead of a flat serie of messages.
Ideally you should probably have this kind of behavior:
Pressing tab goes into the list, pressing tab again goes to the next element outside of it.
Since a single tab is sufficient to skip all messages, the input field to say something can be reached with only two or three tabs
If I want to read the messages one by one, I go to the list, and then can use arrow keys and home/end to navigate between messages in the list. Pay attention to home/end, they are often forgotten, and arrows aren't sufficient in very talky rooms.
When going outside of the list and then back in, the same message should be again focused as when leaving the list
In fact, something often forgotten is that keyboard navigation isn't just about tab. There are as well arrow keys, home/end, spacebar and enter, etc.
There are well written advices on what should do what in which situation on the Internet. Search for example "WAI authoring practice".
IN general, the most useful and most frequent used elements must be quickly reachable.
Keep in mind that if you must press many keys to reach something, you have probably failed in making a well designed interface.
you can use the tabindex attribute :
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
You can set the tabindex number attribute on specific elements. The incremental order of the tabindex will be the selecting order.
Read more here.
I have a webpage and I have managed to keep few accordions in it as well. Since I have given "role"="button" on accordions, my accordions are read as 'button' during accessibility testing.
What should be the aria-parameter values if I wanted my accordions to be read as accordions itself, not buttons?
Can someone give an insight on it? Also, it would be great if anyone can share the accessibility testing standards.
To the average user, a button is a thing you activate to make something happen while an accordion is a musical instrument. The roles you have already are fine.
There is no aria role to describe something as an accordion.
The latest W3C
WAI-ARIA Authoring Practices note includes a section about accordions which uses buttons which is accompanied by a complete example.
My suggestion is:
Use dl element with role="presentation" attribute.
Use dt element with role="heading" for headings of accordion.
Put button inside dt or heading so it will be implicitly focusable with tab order
give button `aria-expanded' attribute and set it to true when accordion panel is expanded otherwise set to false.
Put data in dd element
Here you can find more information with example in w3c
I've seen examples where the tablist role is used for an accordion widget -- which seems very reasonable (https://www.w3.org/TR/wai-aria-1.1/#tablist).
Anyway, WAI does not do that in https://www.w3.org/TR/wai-aria-practices-1.1/#accordion. Instead they demand that the controls to show/hide the panels are buttons (ideally with <button>s and without explicit roles) and that their interaction with the panels is described with aria-expanded, aria-controls and (depending on implementation) aria-disabled. The panel might be a region if you deem the content important enough. Finally, don't forget to make the accordion accessible by keyboard.
I cannot get JavaScript onKeyDown for keyboard keys 1,2,3,4,5,and 6 to work with Jaws Screenreader. Specifically, I have an html document that is automatically generated with links in it. The links are related in different ways (e.g., a series of links related to dogs, and another set of links related to cats). I want the user to be able to switch between the series of links they're navigating through simply by switching the key they are pressing down. This currently works, but not for users of Jaws Screenreader. For them, nothing happens when they press down on the keys.
Other notes: the keyDown event needs to be able to occur anywhere in the document, so it's not isolated to a small area within the document (e.g., a form or a drop-down menu).
Is there a relatively straightforward solution to allow JAWS screenreader users to press different keys to switch between modes? Any help is greatly appreciated!
Are you exiting the normal browsing mode in which 1-6 and other keys are set to jump to various elements? For example 1-6 jump to headings. If not, press INSERT+Space first.
I'm assuming this is an action where someone holds down 1 and then perhaps arrows through dog-related links, or holds down 2 for cat-related links? If so, it seems to me there's probably a more usable and accessible way to implement this. In general, there has to be a really good reason for me to want to learn your site's keyboard shortcuts, especially if I can do the task with approximately the same number of strokes with screen reader native commands.
Essentially the length of the HTML Select drop down is exceeding the screen on notebooks, I've checked and different browsers allow different amounts of options to be displayed before it turns it into a scrollbox. Is there any way of putting in a browser css hack or javascript action to stop it at 3 options? Failing that is there any way to limit the height of the drop down for the same effect?
I've googled up on this but with no such luck, no one seems to have had a problem with notebooks before. I know it's possible as on the Lloyds TSB personal login screen there is a select element which limits to about 3/4 options. As I say I don't mind using JS or even browser specific solutions as I've developed a notebook friendly way of doing it which is less intuitive and clunky looking but can be used as a default.
Any help would be greatly appreciated.
Rupert S.
Sadly, you can't change the item's that the dropdownlist displays, it is decided by the browser, with the size option it will loose its 'dropdownlist' form, and turn more into a list.
You could try finding some Jquery dropdown list, they are usually editable to whatever you want.
I am trying to set up dynamic per-item menus (Edit Control Block) in SharePoint 2007. My goal is to have certain features that are available based on the current user's group membership.
I know that the CustomAction tag that controls the creation of this menu item has a Rights attribute. The problem that I have with this is that the groups I am using have identical rights in the site (ViewListItems, ManageAlerts, etc). The groups that we have set up deal more with function, such as Manager, Employee, etc. We want to be able to assign a custom feature to a group, and have the menu items associated with that feature visible only to members of that group. Everyone has the same basic site permissions, but will have extra options availble based on their login credentials.
I have seen several articles on modifying the Core.js file to hide items in the context menu, but they are an all-or-nothing approach. There is an interesting post at http://blog.thekid.me.uk/archive/2008/04/29/sharepoint-custom-actions-in-a-list-view-webpart.aspx that shows how to dynamically modify the Actions menu. It is trivial to modify this example to check the users group and show or hide the menu based on membership. Unfortunately, this example does not seem to apply to context menu items as evidenced here http://forums.msdn.microsoft.com/en-US/sharepointdevelopment/thread/c2259839-24c4-4a7e-83e5-3925cdd17c44/.
Does anyone know of a way to do this without using javascript? If not, what is the best way to check the user's group from javascript?
There are two different Javascript functions that you can implement for dynamically adding menu items to list item drop downs. Core.js (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033\CORE.JS) checks for the existence of these methods when generating the menu items for a selected list item. "Custom_AddDocLibMenuItems" and "Custom_AddListMenuItems" are the names of the Javascript methods.
One article that I think you can use to solve your specific problem, dynamic menu item customization based on user role membership, can be found here:
MSDN: Customizing the Context Menu of Document Library Items (note the process is exactly the same for any list type)
This article outlines how server side code can be executed to define the menu items that will be displayed:
[...] in more complex cases, you must retrieve the list of available commands from the server, because only there you can run your business logic and perhaps get the commands from a custom database. Typically, you want to do this if you are implementing a workflow solution where each document has its own process state, with commands associated to it.
The solution for this situation is to have the Custom_AddDocLibMenuItems dynamically call a custom ASP.NET page. This page takes the ID of the document library and the specific item on the query string, and returns an XML string containing all the information for the commands available for that particular document. These commands are available according to the document's process status (or some other custom business logic). [...]
Unfortunately this is not possible to accomplish without using javascript. The ECB doesn't render server controls defined as a custom action (unlike the SiteActions etc).
To learn how to accomplish this by using Javascript check out the following article:
http://www.helloitsliam.com/archive/2007/08/10/moss2007-%E2%80%93-item-level-menus-investigation.aspx