I'm hoping to improve the experience for people using screen readers on a site that has a few menu levels with a lot of links (that might feel endless to people hearing every item).
Is there a way of instructing the screen reader what to say? Other than using a link and the SR reading the text (which in this case wouldn't make much sense). I was thinking something like:
"Further filtering of events can be done in the following sub menu. If you do not wish to do so, please tab through the sub menu to the event listings."
I know this isn't ideal; - at the moment I'm trying to figure out how to allocate focus to an element without javascript/jquery so that the tabbing through isn't necessary - but for future reference (for example if an element needs further explanation that isn't a link with text) this would be good to know.
I already have a Skip Navigation link on the page, but that is for the main menu.
Multiple skip links can be used
You could create a hidden link before the menu that allows you to skip it, if that's what you mean. When a user tabs onto it, they would hear your instruction and by selecting it they could bypass the menu.
More information on the WebAIM site: http://webaim.org/techniques/skipnav/
Highlights:
The idea is simple enough: provide a link at the top of the page which
jumps the user down to an anchor or target at the beginning of the
main content.
Probably the most accessible method for visually hiding skip links is
to hide them off screen, then cause them to be positioned on screen
when they receive keyboard focus.
Skip links or other in-page links can also be used to allow users to
jump to or jump over page content. For example, the Table of Contents
at the top of this page includes in-page links to facilitate
navigation to page areas. A "skip" link could also be used to allow
the user to quickly bypass confusing or potentially inaccessible
content, such as ASCII art, complex tables, etc.
The Open Ajax Alliance Accessibility Examples site might help: http://www.oaa-accessibility.org/example/25/
It is difficult to tell from your description whether this is applicable to your situation. If it is then the example site provides a great amount of implementation guidance for incorporating ARIA into your solution.
Related
I've been trying to find an answer to this, but can't quite get a clear one. I'm using a MUI Select component in my app, and noticed that it the menu items are able to be navigated with up/down keys and selected with the enter key, but not able to go up/down with the tab key. Is this a best practice for accessibility, or is it not required? I also looked at this guideline, which seems like tabbing isn't required. Just want need some validation on this. Thank you!
If you mean the different options of a dropdown menu, no, they shouldn't be reachable with tab.
This is probably more a common convention or a recommandation than an absolute obligation, as far as I know.
It comes from native UI control/widget/component conventions on most operating systems that have been in use long time before the web.
The tab key is normally used to go from a control to the next.
But when you go through the different options of a dropdown menu, you stay on the same control.
So dropdown options don't have to, and even really shouldn't be reachable with the tab key.
The same answer applies on the different tabs of a tab control, or the items in a list of selectable items. Normally when navigating with tab, you should only reach the currently selected / active element. Another press on tab key moves to the next interactive control.
As mentioned before, the goal of TAB is typically to move from a specific input control.to another, not within it. Thus, the use of arrow keys and enter is fine. However as a screen reader user myself, I run across custom "selection" boxes that fail to work properly due to many reasons. even if keyboard navigation works as expected outside of a screen reader context. It isn't clear to me if you tried this under a screen reader.
Is it possible to determine the order of HTML elements read by a screen reader (like TalkBack or VoiceOver) regardless of their position in the DOM? I'm wondering if there is an id, an HTML attribute like "voiceindex" (analogous to tabindex) or another option to control the sequence. The corresponding webpage is embedded as webview inside the app. Therefore I don't have access to native Android or iOS code.
No, there is no attribute or anything like you describe to control the reading order of a web page.
Something like this exists in PDF and it's a big mess; for sure it was a very bad idea, making PDF accessibility quite complex.
A web page is read in the same order as elements appear in the DOM and this is always so, regardless of your CSS.
It ahs a great advantage over having to manually specifiy an order: it's simple, you just have to structure your web page using structural elements appropriately; then, to verify that it makes sense for a screen reader user, just read your HTML code from top to bottom and completely forget about visual placement.
This later exercise is widely known as linearization; that's basicly what screen readers do and how screen reader users perceive web pages
If the exercise isn't convaincing enough, imagine that you have recorded your page on an audio CD. You can listen to each title one after the other, or jump directly to the beginning of a track, but not easily jump directly to the middle of a song.
Jumping to the beginning of a track is a metaphore for the jump to next heading or next section of screen readers. Selecting a track from the tracklist is also possible with screen readers as most of them provide a list of sections or headings to jump to.
With the hope that this image will help you structure your page well for screen reader users, and why you should carefully think about it. This was in fact certainly your foundamental problem when you posted your question.
After a decade long hiatus I am dipping my toes into web development again. It still seems a very confusing heap of constantly changing standards to me, making it unclear which browsers support what and what the best practices are.
Currently, I am focusing on using the new semantic elements of HTML5. I found out the ASP.NET Core default Bootstrap template does not use the <nav> element for the navigation bar and was therefore looking into how to apply it properly.
The default navbar template in Bootstrap does recommend to use <nav>. However, I am confused as to what the purpose is behind the aria-expanded attribute applied to it. After learning about the benefits it offers to screen readers (indicating whether the navigation bar is collapsed or not, in this instance when the screen size is small, i.e., for smartphones), I am still confused as to whether it should be there at all. (And whether or not aria-controls should be applied, which it isn't in the default bootstrap template.)
Let me explain:
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
Wouldn't a better alternative be to just hide the navigation toggle mechanism to the non-sighted altogether? Here my question then would be, how to go about this. Can a button be hidden using role="presentation" and/or aria-hidden="true"?
Using the example you cite at https://getbootstrap.com/examples/navbar/, it needs aria-expanded.
In the larger viewport, the "dropdown" menu hides all the sub-items. They are not only hidden visually, but hidden to screen readers as well. The aria-expanded helps give the user context whether or not there is more available, and also gives some clue about where the subsequent tab-stops may take the user.
In the narrower viewport, where the navigation becomes a hamburger, this still applies. Doubly so since it also applies to the hamburger itself.
This context is important since aria-controls support is poop (to quote Heydon).
There are cases where every item in a menu is available via tabbing, even if visually not there. In that case aria-expanded is not so important, but aria-controls would have more value.
Separately, that menu needs better :focus highlighting for sighted keyboard users, and DOM sequence for the menu versus logo in the narrow viewport (through that is my opinion).
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
That question should be the first to appear in any ARIA tutorial.
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
And this one the second.
Edit: When I read those questions, I thought "that guy has already understood everything". ARIA tutorials rarely answer those questions because they are context dependent, but asking those questions must be the first step before using ARIA. Eg. image carousels are for blind people a very different user experience. Giving an aria-controls attribute to the "previous" button does not give more intelligence to a system based on visual effects. ARIA is not a miraculous panacea.
ARIA may be seen as a kind of magic potion for people wanting to make accessible something which is not accessible. In many cases it will be used ill-advisedly.
The aria-expanded can give a good user experience for screenreaders, informing whether or not an element can be opened to show more elements (for instance inside a dropdown menu).
You can't apply the aria-expanded directly on a nav element because it has to be set on an interactive element (like a button) to inform that this controls the visibility of another element inside the same container (which can be a nav).
The better alternative I can see is not hiding anything to also help people not using screenreaders. Instead of collapsing a navigation bar at small screen resolutions, it's perfectly possible to:
always show it
display a persistent menu icon to jump to the menu bar (or temporarily displaying it inside the viewport)
This has the benefit to enable the possibility to scroll to the menu bar (for people not understanding what that icon with three parallel lines may indicate) and let screenreaders users list all the internal links.
Of course, things are very different if you conceive a web application rather than a simple web site, and ARIA might be more useful in that context.
I'm working on a web application where we have a modal panel/dialog popup to collect user data. The form within the panel has grown large and we've suggested splitting the form across multiple tabs, but our client has suggested adding scrollbars within the modal panel.
Are there usability issues with scrollbars within a modal panel? I believe it's a bad practice but I'd like other opinions.
Thanks,
Glen
Update:
I'll explain the scenario in more detail. We have a search page where search result items can be saved (copied into a another area of the system). Additional information can be saved with this items (e.g. additional comments, assignment to other buckets - I can't get into any more detail than that). When a user wants to save a search result item, they can check one or more items and click a save button - that's when our modal panel popups.
Originally, the users were taken to a separate page and they followed a series of pages. Our clients felt this was time consuming, so we changed the page to use a modal panel.
I'm not 100% sure using a modal panel is the best design, but that's what we have now. I welcome any other ideas.
Well, I gotta ask, if you have a modal form that's so long, shouldn't it be made into its own page?
I mean, the whole point of modal dialogues is to tell the user something he needs to know (which are usually disregarded and are annoying) or to get some information from the user that is necessary before proceeding.
You say your form is for gathering user input. If it's something the user must enter before proceeding (as in a part of a checkout flow or something like that), then I would say it's probably best to dedicate an entire page to the flow.
If it's something that's more of a "log in here before proceeding with what you're doing" kind of thing, again, I think it would make more sense for it to be its own page that brings you back to the page you were on before you entered it once you're done filling out the form. That's how the Stack Overflow human-verification page works.
If it's something annoying like "give us your feedback about the site", then it shouldn't be modal at all but rather an easily-dismissed (dare I say it?) pop-up window.
Modal dialogues really should be kept as brief as possible. If brevity is impossible, and the dialogue really must be modal, then I think it would make more sense to create a flow of pages that must be filled in before the next one can be accessed. Like a checkout: you need to add products to a cart before adding shipping information, and you need shipping information before you can determine the cost of the shipment. That kind of thing.
But without knowing the exact nature of your modal dialogue I can't tell you exactly which way would be best.
EDIT: Aha! Your clients felt this was time consuming, eh? This is the type of situation where you should do a very quick and dirty live usability test to see which way is actually better. Grab some people from down the hall, show some of them the modal way (with scrolling) of doing it and show others the old (non-modal) way of doing it and see what they have to say.
(Ideally you are recording the session and the screen, and you make sure to not let your own personal preferences show through. Just ask them to use the system while you watch to see how well they perform the task. Use the recording to time both methods to see if one way really is faster than the other.)
You shouldn't ever make a usability decision that goes against the norm (the norm in this case being "large forms merit their own pages") without making sure that it actually is more usable the abnormal way. When it comes to usability, the norm is usually the norm because it's usable (but not always, which is why you must test). If the client fights back, you'll at least have evidence that they're going against hard empirical evidence that what they want is silly.
Ultimately, though, the clients are the ones paying the bills. If you can't get them to see reason then you'll have to make the most of what they tell you. If the form must be in a modal dialogue, then you can at least try to hide non-essential fields under the fold (if there are non-essential fields) so that the majority of users will never have to scroll.
Make sure the buttons to submit the form (or whatever it is that you need to do with the form) are visible no matter where the user has scrolled. A really bad idea would be to put all the required fields at the top and then force the user to scroll down anyway to hit the submit button. That's just rude.
It seems to make sense to put a modal window here--I assume you're doing it as a layer on the page. But what it sounds like is that it's getting crowded, and you're looking at ways to manage the ever-increasing array of UI elements.
To answer your initial question about scrollbars, no, they are not verboten. However, as another responded asserted, you should never design action UI elements within the scrolling area.
It sounds as if some good user research could be useful here. What items are important to users. Which items are required and which are optional? Can they be categorized?
Some people suggest that tabs are useful for categorization when the number of UI items overflows a dialog box. In this case, though, I think this would be a bad idea. This isn't a setting category of dialog box, but more of a confirmation/selection/entry dialog where users will save whatever is entered and chosen. There's a good chance with tabs that users would miss the tabs and miss entering information. And if something on a "back" tab is required and a user doesn't go there, then you have a really poor error experience.
One of the things about scrolling is that it is easy for users with mice. they have the option of either clicking on the scrollbar or (for many) rolling a scroll wheel.
One thing you may not have considered, especially if some things that users can enter or choose are optional, is to create sections within the dialog box that can be collapsed and expanded. Sections with required elements would be expanded by default and sections with optional elements would be collapsed by default. If expansion of a section adds a scrollbar, that addition to the UI is obvious to users.
Of course, you may have to figure out how all this would work for people who have only keyboards, who have disabilities, and who might be accessing this on a mobile device.
I don’t think a tabbed panel is fundamentally better or worse than a scrolling panel. Each has advantages in different situations. However more important in your case is this: If you need tabs or scrolling then your panel is probably too complex to be modal. The more information input in a modal panel, the more likely a user will need to go somewhere else to get an answer, and the more work you throw away if the user decides they must go somewhere else for any reason.
The solution is to move as much information as you can out of the panel and onto the parent page/window. Let users enter the “additional information” right onto the search results page, allowing them to explore the results to help them decide on the information. Since the additional information apparently consumes a lot of space, make its controls show-able and hide-able, but always preserve user inputs between hides and shows. I think it’s okay to either tabs or scrolling to keep the footprint small. Additional information about a single search result should go in controls next to that search result, rather than in a separate panel.
The modal Save panel should only include a few controls that are instrumental to saving, such as the filename and location, and maybe the file type. If all the information is instrumental to saving, then make the save panel modeless. Who says you can’t?
Putting all the save information on another page is not much better than a modal panel, since that is also effectively modal, in the sense that the users can’t go somewhere else without losing their input. Even if you take steps to preserve users’ inputs to the page if they go to another page, most web-abused users will think they might lose their input, so they won’t try.
I like to display more info on certain keywords in a web page. I don't want to send the visitor to another page and I prefer to show the extra info on top of the current page.
The keywords are in an html list. It's basically a list of features and I want to offer more info about the features. So I have two ideas based on having 'More Info' or '?' hyperlinks.
The user hovers on the link and a popup window shows up with the info and goes away when they hover away.
They click on the link, a popup window with an 'X' shows up and they click on the X to close.
Which one offers a better friendlier user experience?
I like #1 because they don't have to click to open and click to close but the disadvantage is that windows might open inadvertently while they are mousing over the page.
Both are pretty annoying, but if I had to pick the lesser of two evils, I'd go with properly done mouseovers.
You can setup Javascript on the page to handle the accidental mouse over, and instead wait for a few seconds before displaying the popup window.
What would your users expect? Try not to break those expectations.
Maybe try a hallway usability study, grabbing a handful of users as they walk past the office, and just ask them to tell you what they would expect. :)
Asking Stack Overflow is a good idea too, but you won't get the advantage of context, which is very important with usability testing.
As a user myself, I find it annoying when I move a mouse and something pops up unexpectedly. Even with a javascript delay (which is better), I still think it's unexpected that something would pop up when I didn't explicitly click on it.
But, that might vary depending on the context of your application.
Personally, I'd go with the click option. There's a standard Way Things Work on the web which says that hovers are for information about the link itself and what action clicking on it will do ("See more comments", "Click for help", etc.), whereas clicking is what actually performs the action.
If you do decide to go with the hover option, make sure that you code it such that users can select the text in the popup. It's really annoying when you just want to copy some useful information somewhere and the GUI hides it before you can reach it.
Adding to what the others have said, I would also prefer the click option.
The problem I have with the hover option is that, and maybe this is just me, if the hoverable area is on the small side, I have a hard time keeping my mouse still enough to keep hovering. The cursor tends to move off the link in the middle of reading and my nice help text disappears.
People don't expect a pop-up on hover - I'd definitely go with the click.
Edit / addition: think about the website you visit every day - text and pictures are (generally) static, and hovering, at most, changes the colour or add underline to a link, or displays a small menu of clickable links.
When clicking on a link, you expect something to happen - a redirect to another page, a pop-up box with information, a form being submitted, etc.
I'm not saying this is the best way to do things, but it is the way 99% of the web works, and asking users to deal with pop-up boxes on hovers or the like is a good way to turn them away. I know I personally don't read any pages with double-underlined links; it's a good indication that an accidental break in scrolling to read the content might end up with my mouse over a link with an advertisement tied to it.
Having a little graphic beside clickable text, or otherwise denoting that clicking will lead to more information is a great way of providing contextual information without frustrating people. For most of the world, pop-ups without clicking still == advertisements or spyware.
Edit / clarification: I don't mean a pop-up in the new window sense, just a lightbox-style javascript pop-up. Don't take the user away from the page, and give them a very visible button to click to close the pop-up. I guess what I'm saying is that people don't expect something to happen without clicking, especially not if it's going to take up more space on the screen.
As a couple of additional precedents to consider, you might want to consider the functionality of the acronym and abbr HTML tags. Both allow you to provide extra information on a particular piece of text in the page, and both work on the "hover" principle.
Points to ponder:
If items are so dense that everywhere you move the mouse something pops up on hover then do NOT do hover!
Can you make hover show very brief info, and have click show more detail? This may be the best of both worlds if it works for you.
Can you have a dedicated box that displays info when you hover? This may be better than any pop-up. Opinions vary...
In the end it's what works for your app, from your users' point of view.