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.
Related
We have a web-based app which uses a side-by-side experience for desktop users where the left side of the screen is a file browser and editor and the right side of the screen is an interactive preview. Users of our app will make constant and iterative changes on the left and and then interact with the preview on the right, switching back and forth many times in quick succession.
Is there a "best practice" for allowing quick and easy navigation between these two interactive areas? I know this might fall under the "opinion" category, but I feel that accessibility is such an overlooked topic that it helps to have as many resources as possible.
You have a few tools at your disposal.
Headings
Headings are one of the easiest ways to bake in some super simple section switching. Screen reader users will use the keys 1 through 6 to navigate by heading levels so if both of your panels are <h2>s (for example) they can simply cycle location using headings.
Keyboard shortcut keys
You can set keyboard shortcut keys.
However you should never do this in isolation. By this I mean if you say that switching window is say Alt + 0 you must allow users to be able to change these key bindings to their preferences.
This is so your shortcut keys don't interfere with their screen reader keys (as they may have set custom keyboard shortcuts).
please note: as pointed out in the comments this is not a WCAG requirement for key combinations (which is only for single keys) but is a usability best practice and highly encouraged, especially as some screen reader users use a modifier key rather than a toggle key for screen reader navigation.
Then we get into an interesting area which I like to illustrate by saying "how would a one handed user use your page?".
This example makes you realise that some sort of sticky keys solution may also be considered where key combinations can be done with a sequence of keys, any time apart (as you may have someone with NO HANDS using eye gaze technology or a switch for example so you don't want to impose a time limit.)
Obviously the above are extreme examples but things you may want to consider (and in reality anyone using eye gaze would be able to visually switch panels etc.)
Voice commands
Being able to switch panels via voice (for example Dragon Naturally Speaking) is also essential.
Now you can do key combinations with voice software so that fixes most issues but they can be annoying and fiddly.
One thing that is quick to use on most voice software is clicking any button on a page with a unique name.
As such having a button above each panel that activates it would be beneficial to voice users.
Assuming these buttons have unique names I could simply say "click activate panel 2" (where "activate panel 2" is the button name) and switch immediately.
Do you need to manage focus?
Bear in mind that when you switch panels you will by default start at the top each time.
This may be exactly what you want but more than likely this would be a terrible user experience.
Instead you may want to remember the previous focus location. Then if I use the keyboard shortcut it would jump back to the same location in the panel. If I use the voice / button click to change location same again.
However if someone uses headings to navigate this obviously wouldn't work. You could then give them a button directly after the heading that says "resume from previous location" to fix this and use that to manage focus.
User settings
As you can see there are loads of things that different people with different requirements may or may not need.
As such adding all of the features by default would probably make the application worse to use for majority of users.
Instead have a settings screen that lets a user turn on features that benefit them, set their own shortcut keys, turn on or off sticky keys, decide if they want you to manage focus for them (or not) etc.
This is a difficult problem! I have been giving a similar issue a lot of thought. I have outlined one idea that uses ARIA live regions, and an alternative idea that might work better if quick-jump keyboard support is vital.
Live region announcements as part of a <form>
The <output> tag may be what you're looking for. It is mapped to the ARIA role of status so any changes to its content will be announced without any focus change. That way, the user can continue to navigate and make changes on the left side without always having to flip over to the right side to know what changes were made.
The role status has an implicit aria-live value of "polite", so that the announcement will wait until any other descriptive announcement is finished.
It has an implicit aria-atomic value of "true", which means that any change will trigger the announcement of the entire contents of the element -- which may or may not be appropriate for the content. If not, add aria-atomic="false" to read out only the changed node.
If the content inside the <output> could be anything other than phrasing content (including <div>s or heading tags) then you should use a <div> with the role attribute of "status" instead.
Custom keyboard controls can get tricky with various types of assistive technology (AT) software/hardware. Plus those commands probably can't be made easily discoverable. Some ATs provide a keyboard command to flip between a controlling element and the element assigned via its aria-controls attribute. Unfortunately, this functionality is poorly supported, but it is the current standard, so support may get better over time. Currently only NVDA on Windows supports it, with the keyboard command Insert + Alt + M.
Adding aria-controls to an element controlling an <output>/status is mandatory anyway, so give it a unique id attribute and set that as the value of aria-controls on each form element inside the <form>.
If the <output>/status is wrapped in a <fieldset> and the inputs are all wrapped in a containing <fieldset>, then each <fieldset> acts as a grouping container, so the user can navigate between them quickly. As part of this, ensure the <fieldset> containing the <output> directly follows <fieldset> containing the form elements in the source order. If this isn't possible, add the aria-owns attribute to the containing <form> and reference the id attributes of both <fieldset>s with a space in between.
Always-open non-modal <dialog>
You may instead consider making the right side pane an always-open non-modal <dialog>. A <button> next to each interactive element on the left pane would move focus to the <dialog>, and the Escape key would return focus back to the <button>. Focus isn't trapped within a non-modal <dialog>, so the user can still move between each pane using normal navigation methods. The <dialog> needs to have an open attribute to appear and it also needs to have aria-modal="false".
Each <button> would need an aria-controls value referencing the <dialog>'s id attribute, and an aria-haspopup value of "dialog". The <button>s could be invisible until focused.
There's only a single focused point at any given time. So there isn't any real miracle solution, screen reader and other keyboard-only users will necessarily have to repeatedly go back and forth.
IN fact, the most important isn't to be able to switch quickly between the different parts (you must only somehow give a way to do it only with keyboard), but to not lose cursor position when you switch.
For example if I edit something on the left, go to the right to check the result, and then go back to the left side, I expect to find the insertion point exactly where I left it off.
You really have to make sure that this is always correct, and as closest as possible when changes occurs (especially when it's asynchronous, i.e. a change occurs on the right side when you are on the left side).
The most similar accessibility recipe or component is probably split view.
In windows world, the most used shortcuts for cycling between the different splitte parts is F6, and Shift+F6 to cycle in reverse direction.
Don't hesitate to add other easier or additional shortcuts if the switch has to be really frequent, such as Ctrl+Tab, if such shortcuts aren't already used for something else.
F6 and Shift+F6 aren't the easiest shortcuts to perform, especially on laptops where all F1-12 keys may not be available at all or only by using an additional FN key. I personally always found F6 a questionnable choice, but that's only an opinion; at least we have something and that's of course better than nothing.
However, don't replace an existing shortcut commonly used. (for example Ctrl+Tab = switch between different tabs, don't use it for cycling between views if there are tabs in your application and keep it for the tabs)
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
I am going to write an application that uses QT4 (with C++ or python it isnt important in that moment).
One of functionality is "Showing all items in database".
One item has a Title, author, description and photo (constant size)
And there could be very many items. Let's say 400. There won't be enough space to show'em all at once time.
One row will have 200px, so i need at most 4 for once time.
How to paginate them? I have no idea.
I can use limit and offset in SQL queries, but how to tell window: "that's 5th page"?
Any solutions?
First off, you normally do not want to use any manually set pixel widths in any GUI application, if you do, your toolkit sucks (or you must work in game development).
Second off: be more specific.
You'll need to define "page" for your application, namely what a page should be in its context. I assume it is breaking a list of items into separate pages. Normally this is done by using one of the view classes (e.g. QListView or QTableView) to take care of much of the legwork: it's called a scrollbar (not to mention the collapsing folders concept from file managers). Another method is splitting the information across several tab pages (QTabWidget), where each page displays a view of some sort (Perhaps QTextView or one of the M/V or Item view classes).
Same thing can also be done using your own widget stack and some other widget to manipulate the currently displayed page. This is basically how the option dialogs in the TeamSpeak 3 client and most KDE apps work; it's also how wizards with back/next buttons work in concept. I suggest you take a look at this config dialog example
Normally what you want is a view with a scrollbar and or some form of collapsing related entries into categorised information. If you just want to display a list of pages where each page is X entries: use a tab widget or stacked widget.
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.