Re: [WSG] accessible drill-down into a nested list
Paul Novitski wrote: Tell me if this would be a better scenario: When you select a menu item, the page reloads with a set of breadcrumbs that spells out the history of selected menu items, such as: Thanks very much, Ian, your response to my posting was exactly the kind of feedback I was looking for. I think you may have mistaken my negative example for my recommendation, but I appreciate your remarks all the same. At 02:57 AM 2/13/2006, Ian Anderson wrote: I think you are correct to be concerned about the issue, but this may not be the optimal solution. If you consider the requirements of a screen reader user, their task is one of wading through immense amounts of irrelevant stuff trying to find the thing of interest at that moment. What's of most interest at the moment you're describing is hearing the *new* options that are now available. ... That's precisely the issue I'm aiming to address: boiling the repeat information down to the bare minimum (menu selection breadcrumbs to tell you where you are in the menu tree) followed by the new options opened up by your most recent selection -- NOT repeating the whole damn menu each time, except perhaps at the bottom of markup where it can be read at the user's discretion. Here's what I'm envisioning: ___ [Site title (home page link)] [Page title] [link to complete navigation menu below] [list of menu breadcrumbs (links): [selection from 1st level menu] [selection from 2nd level menu] ... ] [list of new options (links)] [page content] [complete navigation menu] ___ Warm regards, Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] accessible drill-down into a nested list
Paul Novitski wrote: Tell me if this would be a better scenario: When you select a menu item, the page reloads with a set of breadcrumbs that spells out the history of selected menu items, such as: I think you are correct to be concerned about the issue, but this may not be the optimal solution. If you consider the requirements of a screen reader user, their task is one of wading through immense amounts of irrelevant stuff trying to find the thing of interest at that moment. What's of most interest at the moment you're describing is hearing the *new* options that are now available. The breadcrumb (hierarchical location) is also hugely appreciated as a means of keeping track of where they are in the site. From user testing we've done with screen reader users, the most important thing is that the page title and main heading on the page are descriptive. The page title is read first as the page loads, and then the behaviour depends on the screen reader in use. JAWS will typically skip over stuff that has been seen before, and try to jump to the first new content on the page. If the page title and heading don't change, this can be very destructive for these users, as they start trying to backtrack or reload the page to see what has gone wrong. In the scenario you describe, is the page more or less identical except that a new submenu has appeared in the navigation area? I think this would be very harmful UI for screen reader users. The chances of them locating the submenu are remote, and the chances of them realising that it represents hierarchically subordinate options are too. The best solution for these users may be to create menu pages that contain the submenu links as primary content. Ensuring that navigation links come after content links in the source order may also be very beneficial, as these downward or onward links are much more likely to be what the user is looking for. Somewhere else on the page, perhaps last in the markup, would be the full menu including all menu items at each selected level. A jump to navigation link early on the page could get you there quickly. I think this would be immensely bad design for screen reader users. This is a site map. What you may be missing is that too many links are the bane of a screen reader user's life. They rely on using links as a kind of binary tree to navigate the site - the last thing they benefit from is hearing links again that they have already discarded as not of interest. They go back much more than sighted users in order to find a link they heard before. The other interesting thing is that screen reader users build a mental map of a site that is nothing like the real architecture, based on the links they hear. If every link is on every page, all pages sound the same to them, because about half of a user's time on each page is spent listing the links. When the links on each page are mostly unique, screen reader users perform better in tasks. So, have a site map linked off each page, but don't include extra links on every page - these are bad for screen reader users, not helpful, in my opinion Hope this helps Cheers ian -- _ zStudio - Web development and accessibility http://zStudio.co.uk Snippetz.net - Online code library File, manage and re-use your code snippets links http://snippetz.net ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] accessible drill-down into a nested list
Ian Anderson: I think this would be immensely bad design for screen reader users. This is a site map. What you may be missing is that too many links are the bane of a screen reader user's life. They rely on using links as a kind of binary tree to navigate the site - the last thing they benefit from is hearing links again that they have already discarded as not of interest. They go back much more than sighted users in order to find a link they heard before. The other interesting thing is that screen reader users build a mental map of a site that is nothing like the real architecture, based on the links they hear. If every link is on every page, all pages sound the same to them, because about half of a user's time on each page is spent listing the links. When the links on each page are mostly unique, screen reader users perform better in tasks. This is great, I'd really like to send this as a reply every time someone asks about dropdown menus ;-) The lack of uniqueness in link labels and too much navigation (e.g. the site map on every page) affects all users not just screen reader users. I recently completed user testing for a navigation system with 165+ links in it. Most tasks were eventually completed though not without error(s). We observed a lot of backtracking, confusion over similar (i.e not unique enough) labels and false positives (where users were confident the task was complete but they were not in the prescribed location). Most users requested additional contextual information (e.g. tooltips, or deks). So indications are, IMO (based on this, and my recent reading of Spool on global navigation) that less global navigation, and more contextual navigation is generally better for content rich sites. kind regards Terrence Wood. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] accessible drill-down into a nested list
At 11:26 PM 2/11/2006, Terrence Wood wrote: the page reloads with a set of breadcrumbs that spells out the history Essentially you are repeating information already available through the browser history, and it still doesn't inform the user that there is a new menu if that is your goal. Also, breadcrumbs are most commonly links to parent directories in the site hierarchy, so there may be some issues here - you might need to test it with real users. Perhaps I shouldn't have used the standardized term breadcrumbs. What I meant was a sequential list of nested menu selections, NOT necessarily the same as the browser history. For example, while drilling down in a nested menu I might digress to a side-page then continue drilling down. The menu breadcrumbs I'm suggesting would not reflect that horizontal digression but only the vertical descent in order to convey the user's position in the nested menu structure. I recommend reading Hudson, Weakley and Miller's work on source order and structural labels: http://www.usability.com.au/resources/source-order.cfm Thanks, Terrence. Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] accessible drill-down into a nested list
I'd like to hear from folks who've used screen-readers: What are the best ways to drill down into a nested list? Consider a nested menu that's marked up as an unordered list (UL). Select an item in the top-level menu and the page reloads with a second-level menu of items opened up within the selected top-level item. Select a second-level item and the page reloads with a menu of third-level items opened up within the selected second-level item. In a visual menu it's usually sufficient simply to open up these sub-menus. Because the parent menu remains the same, our gaze immediately jumps to a new sub-menu that's appeared the screen. We don't have to re-read menu items we've already read, because we can tell at a glance what parts of the menu we've already seen and what parts are new. However, it must be a very different experience using a screen-reader. When the page reloads, I assume the screen-reader begins reading the menu from the beginning again. The user would have to listen for a new sub-menu, but without really knowing for sure whether a new sub-menu had appeared. If this is the scenario, then browsing with a screen-reader must require a great deal of patience as you wait through the repetition of the menu each time in order to discover the new list of sub-options. Tell me if this would be a better scenario: When you select a menu item, the page reloads with a set of breadcrumbs that spells out the history of selected menu items, such as: portfolio : music : compositions After the breadcrumb list comes the current sub-menu, in this example a list of compositions. Somewhere else on the page, perhaps last in the markup, would be the full menu including all menu items at each selected level. A jump to navigation link early on the page could get you there quickly. Please let me know if this scenario would work for you, and if not what other menu functionality would best suit the screen-reader environment. If this description isn't clear, let me know and I'll prepare a live demo. Thanks, Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] accessible drill-down into a nested list
Paul Novitski wrote: When the page reloads the screen-reader begins reading the menu from the beginning again. Correct. The user would have to listen for a new sub-menu, but without really knowing for sure whether a new sub-menu had appeared. Correct. browsing with a screen-reader must require a great deal of patience as you wait through the repetition of the menu each time in order to discover the new list of sub-options. Correct. the page reloads with a set of breadcrumbs that spells out the history Essentially you are repeating information already available through the browser history, and it still doesn't inform the user that there is a new menu if that is your goal. Also, breadcrumbs are most commonly links to parent directories in the site hierarchy, so there may be some issues here - you might need to test it with real users. After the breadcrumb list comes the current sub-menu If you are talking about unnesting the sub-menu then, yes, this is good. Some screen readers don't announce the end of a list so the whole concept of nesting is lost. See also link at end about structural labels. Somewhere else on the page, perhaps last in the markup, would be the full menu including all menu items at each selected level. A jump to navigation link early on the page could get you there quickly. As a develpoer I prefer a noun form for navigation (e.g. main navigation, page content) and drop the verb (e.g. skip to, jump to) there are some reports of screen reader users not understanding the purpose of skip links and thus ignoring them. Please let me know if this scenario would work for you I recommend reading Hudson, Weakley and Miller's work on source order and structural labels: http://www.usability.com.au/resources/source-order.cfm kind regards Terrence wood. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
