I am creating a rating component , and wanted to add accessibility feature to it. What all aria-attributes has to be added? What are the tab navigation required?
i.e how it should behave on right/left arrow click or click on other keys?
There is probably no unique definitive answer to this question. You may design your component rather differently, depending on the exact desired behavior.
Is your rating component read only ? Can the user rate only once for all or change his mind at any time ?
When the user sets or changes a rating, is it taken into account immediately or does he have to click an OK/save button ?
Are three of the few questions that may change things.
For example, probably the simplest:
you may view your component as a serie of radio buttons labelled 1, 2, 3, ... 10.
If you use true radio buttons <input type="radio"/> with accompagning labels, you have very little to do to make your component accessible.
A bit harder, you may see your component as being a slider. IN this case it's going to be more difficult because you will probably need to use some ARIA.
Refer to W3C authoring practice for implementing it correctly.
This was for a component allowing input. Now if your component is read only or become read only once the user has given a rating, remember that, after all, a rating is just a ratio between two numbers, the rate obtained and the maximum possible rate.
How fancy you present the result to the normal user has finally little importance as long as you give the two numbers in text somewhere, e.g. "4/5" or "4 starts out of 5" in a place and in a form where it can be read as is. The rest is pure optional decoration.
However, if you really don't want to give the numbers in clear somewhere, you are going to fail. For example, color blind won't see if it's green or red, screen readers users won't figure out the size or number of bars, etc.
I can well understand the willing to hide exact numbers for many reasons, but it's a bad idea for accessibility.
Related
I have a component which presents an x/y axis plane and a nub that users can move around within the plane. Some aspects of accessibility here seem pretty straight forward: the nub should be focusable; keyboard up/down/left/right should move the nub by some interval to increment the x/y values in the appropriate directions. Even with a secondary text input, these behaviors for the widget-proper may be helpful regardless of whether users are employing assistive technology.
But when I began investigating how I should mark this up aria-wise, I wasn’t sure what the appropriate role/roles should be, or what the best way to communicate the available functionality is.
The closest match for a role appeared to be "slider":
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_slider_role
However the slider role as described on MDN seems like it may be specific to single-axis sliders.
A slider is effectively 1D only, so it isn't the appropriate role.
To convaince of this, read the description of slider in ARIA 1.1.
http://www.w3.org/TR/wai-aria-1.1/
Nothing in the description mentions that you may use something else than simple numerical values, comparison between values should be unique and total (for 2D points it is not), and it also reads the following:
Elements with the role slider have an implicit aria-orientation value of horizontal
It's horizontal; it may certainly be vertical; but definitely not both at the same time.
By the way, by default, Jaws for example announce more or less this for a slider: "left right slider. Use left and right arrow keys to adjust the value" which is wrong for your case.
IF you were in a discrete plane, I would have suggested grid/row/gridcell. But since you are selecting coordinates in a continuous plane (or almost),
your case is special / unconventional, hance there doesn't exist a predefined ARIA recipe you can apply.
IN such a case where there is no really adequate role, tehe best play is probably to not indicate any role at all for your component.
An assistive technology will therefore not confuse the user by telling him what your control is not really, nor by giving him wrong indications on how to use it. No indications at all is probably better than wrong ones.
You must of course still use aria-label/aria-labelledby to give your component a label, make it focusable and keyboard usable.
You should also ideally compensate the absence of predefined role by giving precise keyboard usage instructions. For this, keep it rahter short in aria-describedby (which might be read each time the control is focused), and if needed / if the control is quite complex, explain it longer somewhere else with plain text.
IF it's really too complex, you are also allowed to give up, as long as you provide an acceptable alternate input mean giving equal possibilities. For a color chooser, enter RGB value or #XXXXXX code would certainly be acceptable and sufficient alternate input means.
Introduction
An HTML form contains a checkboxes element listing various indicators. The user may choose exactly three items from that list (see image 1). Upon submitting the form, a bubble chart is created, with one indicator each on the x and y axis and the third indicator defining the size of the bubble (see image 2).
Image 1
Image 2
Problem
By choosing the indicators, the user is not able to define the order of the selected indicators. Thus, the user is not able to define, which indicator is on which axis or which indicator is responsible for the bubble size respectively.
Available solutions
Of course, instead on having a single multi-select checkboxes field in the web form, (1) one could create three single-select radio elements named x, y, and z. Or, if the form is ajax-powered, (2) additional form elements could be shown to let the user choose the respective options.
However, with option (1), the indicators would be repeated thrice in the form and with option (2) the additional form elements would not be inside the list of indicators. Further, I would like to keep the indicators in one element due to the fact that there are other chart options using a very similar form (they are all generated from the same toolbox) and the processing functions are relying on specific element names (not types though).
Questions
I've read about multi-state checkboxes, however, the (only) additional state (indeterminate) is just a visual representation, the checkbox must technically still be either checked or unchecked.
Q1: Is there another (similar) form element which could be used?
From what I read, I would assume, that such an element doesn't exist since what I am practically trying to do, is to send two values (indicator id and chart representation).
Q2: Could someone point me to UI/UX best practices for similar cases?
Due to the lack of correct (search) terms, I haven't quite found good examples of solving this or similar situations. "multi-state checkboxes" bring up the before-mentioned indeterminate state, "ordered checkboxes" mostly refer to some MS Excel problems.
What if I want to have the Biomass for x and z?
UX is a very difficult topic, and denying choices from a user doesn't make them happy at all.
So my solution, not to the technical question, but the UX one, would be to convert all check boxes to radio items and add an additional selection (either as a dropdown or again as radio items) with which you select either x,y or z.
This can easily be achieved via js and solve the problem at hand easily. Another advantage is that you only use controls with which users are already familiar with, which might be an additional plus :)
I am creating an application where users can create cards and decks of cards.
One thing they can do is create a card and share an instance of it among decks. So if they modify this card all the instances in all the decks will be changed too. This is very useful in my app however it might surprise users so I want to explain this in a simple way.
How would you go about explaining that? As programmers we all know what instances are, but are regular users familiar with the concept? Should I use the word "instance" at all or is there an equivalent word with which users would be more familiar?
I don't think "instance" is a completely terrible term to use, but maybe an alternate way to explain it is something like:
Every card that you create is unique. No matter how many decks you add your
card to, only one actual copy exists. Modifying the card in any one
deck will cause the same updates to automatically appear in every
other deck that includes the same card.
...or some such less verbose variation.
You can invent some word for such cards. And explain in short, that changing properties of 'MAdeCards' will be visible everywhere. And avoid the word 'instance'.
I would look at it the other way, and call the instances just 'cards'. The 'template' or 'class' could then be called a 'card type'.
What about telling them about the hierarchical part of OOP? A card has a father and a mother for it's left and right pointer. A card can have children (again for it's left and right pointer). It's most likely that every children of a master card share his attributes. An outstanding attribute of the master card is the unique attribute. If the master card is modified in way all it's children gets modified in the same way without any delay?
I'm going to buy a new mobile phone (cell phone). Or a car.
That's a class:
hypothetical at the moment
don't have it yet to use
no state (eg no battery to have a charge or don't know what fuel will be in the tank)
I've bought a new Samsumg or Audi. That's an Instance.
I can play with it ("Instantiated")
I can measure things eg battery charge etc ("State")
Non-techie folk don't care about our day to day concepts so don't even use "Instance" maybe
In the real world, one card would not be in several decks, let alone all decks. At first glance, your model doesn't make sense to me...
Instance can be replaced by 'Edit Master Card' and also you can have text assistance next to the link / button "Note: The modification would reflect in all of your existing decks". Hope you can rephrase the content how the way the 'target user' wants. You need to check with the target users with the button and help text whether this information is well receive by them, or else ask them suggestion in what way they get it easier to rephrase it then consolidate the response and conclude.
I need to create a dropdown, which can contain 100s of options.
I need a scrollbar to appear and be consistent across all browsers.
Google came up empty: Is there a good URL that describes if this is consistent or not?
I would strongly recommend against having a scrollable select with 100s of options for usability reasons.
With exception of one corner case, navigating (both searching in, and selecting from) that list is a really really hard and very annoying to the user.
The UI design reasoning is that it requires:
Wide mouse gesture (tiring), followed by immediate precise stop (hard to do because of inertia)
Very difficult to use interface of a scrollbar (extra crap points for scrollbar being in the middle of the page instead of on the right side) - see Jacob Nielsen's and others' usual ranting about difficulties of using scrollbars and general evil of anything too long that requires much scrolling.
Eyes need to scan whole page worth of menu up and down and back, all the time. very tiring.
Here is a set of bad examples
[ the corner case is when all the option names are uniformly distributed across the alphabet (as far as the first letter), which allows somewhat-possible keyboard-only navigation in the drop-down via pressing the first letter of an option ].
A proper UI solution is to have a select whose contents are dynamically populated based on a search field - either typed text (think Google's new search box, or browser's address bar) or sometimes checkboxes/radio buttons.
BTW, sub-menu solutions also suck for mouse navigation - minor twitch of the wrist and you lost all of the pointing work.
I apologize that this answer is not an answer to "how do you solve my technical problem", but I am of a very strong opinin that you're solving the wrong problem in the first place.
HTH.
The short answer is no, for the standard HTML select element and the requirements you describe.
However, do you know you can set the size attribute for how many rows are visible at one time? AFAIK this will force scrolling in all browsers, but it isn't a drop down. Like this:
<select size="10">
<option>etc</option>
...
</select>
There is also the possiblity of optgroup to split the options into categories.
If you have many categories you could do what I did on one site and use this jQuery click menu, using the click function to set a hidden field. So now I have a dropdown with sub-categories and it's quite easy to find the right option.
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.