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.
Related
I have a complex multi-column form that the NVDA screen reader reads perfectly well after the page loads, including aria-labels, fields, order of elements, etc. In this working scenario, the form is fully visible when the page loads.
However, I need to hide this form by default when the page loads. This form should only appear if the user clicks a "Show form" link on the page, setting the form from "display: none" to "display: block".
By default, the reader won't automatically read the form after I click "Show form".
So I added aria-live="polite" to the form. The reader will read the form when I click the "Show form" link, but the reading is very poor - things gets mixed, aria-labels get ignored, the reading flow breaks, etc.
So my question is, using a screen reader like NVDA, how do I get a clean and accurate reading of an element that goes from display: none to display: block (based on some user interaction) after the page is loaded?
As I mentioned above, I get a perfect reading only if the form is visible when the page loads.
Aria live regions are only read in two occasions:
When they are added in the DOM
When their content changes
IN all other cases, it isn't officially specified if they must be read or not. They are with some browsers + screen readers combinations, but not with some others.
IN any way, it isn't a good idea to read an entire form section.
If the user can quite well expect something to appear, it's much more important to make it naturally reachable, than to announce the fact that it appeared. By naturally reachable, I mean both by tab and by browser cursor commands like arrow keys or navigation from form element to form element.
In particular, it means that you should for example avoid adding new content at the end of the body, but rather add it in the DOM where it is really expected instead.
Once this is correctly done, at that moment you may think about announcing that the form section appeared. You shouldn't make the whole new section being read, but stick to a simple general message, like "Personal information section appeared below general information". This kind of message has to be in an aria live region.
If that form section appears quite unexpectedly from the user point of view, this announcement can be really useful. If what happens is quite expected, that announcement is relatively optional, if you have made it appear at the right place.
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 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.
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.
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.