Above you se a typical breadcrumb.
Sometimes there are to many steps in that breadcrumb, so we have to shorten it by replacing some of the steps in the middle and display three dots instead
When a user clicks on the three dots, the entire breadcrumb is visible.
How would you handle the accessibility issues here?
We would like to show all the steps to our screen reader users so those users can tab trough the entire breadcrumb whiteout ever knowing about those dots.
All other users will only be able to see those tree dots.
We can accomplish this in a few ways:
Use display:none but this will hide the hidden content for all users, including screen readers
We can use the class.sr-only (since we're using Bootstrap) or something similar on those hidden links so only users with screen readers will se the hidden parts of the breadcrumb. This will work, but it will remove the hidden parts breadcrumbs from the tab order.
We can stick to #2 above and add taborder="0" to those hidden links in the breadcrumb, but then we also have to add taborder="0" to every single interaktive element on the entire site and that is NOT an option. :-)
Are there any other ways to include the hidden links in the tab order?
(Sure, one can discuss the UX aspect of abbreviating a breadcrumb, but that's perhaps another topic.)
(Sure, one can discuss the UX aspect of abbreviating a breadcrumb another topic.)
This is perfectly the topic.
Blind person are normal people who like simple things. If you think your breadcrumb is too long, give them the same functionalities :
<button aria-label="view full breadcrumb">...</button>
Breadcrumbs have not been invented for blind people. They are part of one technique in a WCAG AAA guideline which implies that : it's not mandatory, and that it concerns everybody.
If you include hidden links in the tab and speech order, you are sure that your website won't be accessible.
A near-blind person using a screenreader in support of his eyes won't be able to view a link on the screen while it's announced by the screenreader.
A person using a keyboard only system will focus an invisible link which will remove the predictability of the focus order.
Note that for 2/ and 3/ the sr-only does not remove the elements from the tabindex, so this will work as you would expect
Related
I have a Mobile design to fulfil:
The menu is a fairly standard Accordion setup.
It starts collapsed.
Tapping anywhere on A will expand it to show the A sub-menu.
Tapping anywhere on B will collapse A and expand B.
Tapping anywhere on A Sub 1 will take you to that link.
All standard so far! But the additional Feature is that A is itself a page that the user might want to access!
We have to fulfil this very specific design, so we can't add expander controls, to separate the link from the expand.
I was originally using simple nested <ul> lists and some trivial JS to bind into the onclick events. That was fine for elements that were links OR expanders but that fell apart on bits that were both.
I tried changing the behaviour to exposes the submenu on hover, to utilise the behaviour that I discovered, and documented here: Tablets hover on first click, click on second click
That does technically work, but not very well: you can't scroll the menu properly because touching outside your current expansion will change the selection; the hover exposure of the submenu isn't animated; it generally doesn't actually work well for phones and on a small desktop screen it's completely unusable.
I've looked for ages online for an example or a library that will Just Do This, but nothing fits what I need, and we've been given this very specific design spec.
Currently my only solution is going to be to implement the 2 phase clicking myself in javascript, storing the current state of the element in data attributes and reading those before deciding what action to take on click.
Is there any better way to achieve this?
=-=-=-=-=-=-=-=-=-=-=-=
See here for SO posts about related scenarios for a traditional navbar menu:
Tablets hover on first click, click on second click
https://stackoverflow.com/questions/29354150/deactivate-hover-on-tablet
You just need sit at your computer and watch for responses in about 50 years when all programs will include multiple touch, voice recognition, and thought features to accommodate your functionality request.
Personal experience dictates this problem will not be solved in less then 5 to ten years based on Moore's Law and general apathy on the internet.
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.
are multi-level CSS drop-down menus a big 'no-no' for SEO purposes.
i've read mixed reviews. some say the links in the secondary navigation will not be crawled by search-engine spiders (because they're hidden) while the other say it is part of the HTML, so the spider will 'see' it.
any thoughts? thanks
As long as Google doesn't publish their indexing methods, we will never know for sure. But I very much doubt spiders will ignore links because they are in hidden elements. Text and keywords, yes. But links? No. In my experience, all bots are greedy to index as much of the internet as they can.
If you want to make really sure, consider having a second menu that is never hidden, and that shows the current page's "neighbor" links. Maybe have all the links of the current category as small links in the footer. That way, you can be sure every link will be visible on some page that is reachable from a level-1 link from another page.
Actually, I think I have seen sites doing that even though they had drop-down menus. Maybe that's the reason.
Depending on the number of links on your page, from what I understand you can be penalized if there are too many. With that in mind, how many are in the content, sidebar, etc. They add up fast - I don't use drop down because I did a test group and a large majority do not like sites with drop down menus.
IMHO will be seen. The search engines can not run all the javascript to figure out whether something MAY become visible during normal operations.
I've made sites using a drop down menu and they got spidered perfectly fine. As long as the links are in the HTML output (e.g. as an ordinary list) then the links will be seen.
If i have same navigation on 2 places in every page , one is in dropdown and again is in left sider bar will it create difficulties for screen reader user?
Short answer, NO. Longer answer, it will be redundant for the listener. The reader will present the page in document order, not rendered order, so you can use the CSS positioning to arrange that one copy, the less useful copy to a reader user, will occur last.
It shouldn't be an issue. Assuming the drop down is a combo box there won't be duplicate text spoken since screen readers only read the selected item in a combo box by default not the entire list of items. I find links are the best way for me to navigate a frequently used page since most screen readers have the ability to generate a list of links, and I can use first letter navigation to get to where I need to go instead of cycling through a drop down with lots of choices most of which I probably don't care about.
You might like to add a "skip to content" link as the first focusable element on the page to let people jump past all the navigation if it's very long or repetitive.
I am developing a public website which is the front end to information about medical conditions.
After the user does a search (questionnaire based) they are presented with the results which are categorised in to sections and sub-sections.
Information items can be assigned to both sections and sub-sections.
At the moment sections are represented by tabs across the top and the screen and sub-sections by links in a sidebar. The links in the sidebar change depending on which section is selected.
The problem is the section names are quite long (several words) and as a result the combined length of the tabs is too wide for a standard screen resolution (1024 x 768). Therefore they wrap and break the page layout. We will also have to add additional tabs in the future.
With this problem in mind and the fact our target audience is quite wide, this is a public medical website, what options are there for presenting this kind of information in a way which is accessible and easy to navigate for an average user.
How long are the subsection names? Will they fit in the space for tabs? You’re likely to get better user performance if you put the section links on the side bar menu and the subsection links in the tabs, rather than the other way around. See http://www.usability.gov/pubs/040106news.html.
The other alternative is to put everything on the side bar menu. Subsection links can appear indented under their section links. You can also consider putting the subsection links in a column of their own to the right of the section column. This makes the section menu stable, but takes a lot of horizontal space that’s perhaps better used for content. In either case, proper attention to visual design will show the current section, subsection, and the link between them.
There shouldn’t be a problem with accessibility as long as you’re using links to navigate to each section/subsection (perhaps generated programmatically for each page based on a database relating links to pages).
Just brainstorming some ideas:
Use combo boxes to allow the user to select the (sub)sections, then display the appropriate information items.
Create separate pages for each section-level and provide a bread-crumb control to show the user where he / she is in the page hierarchy.
Create some sort of fold-out menus that automatically hide when the user reads an information item.
In another question on SO, I came across a link to Quince, perhaps you can find some inspiration there as well.
You could try:
An iPod-style menu (in which subsections are hidden pages that fly in from the right): http://www.filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/
Or as Daan has said:
Cascading drop-down boxes: http://www.asp.net/AJAX/AjaxControlToolkit/Samples/CascadingDropDown/CascadingDropDown.aspx
The downside with both of these (over a traditional tree view) is that the subsections aren't visible until you choose a section. If your users don't know the name of the subsection they're after, then either of these will be a good fit.
If, on the other hand, they do know the name of the subsection they're after, it's probably better to give them an auto-complete textbox so they can type a few characters and go directly to it.