Well, I curious as to the nature of Radio groups and dropdown lists in HTML. I have found that radio buttons are difficult to style but I would like to style my elements for required fields. I asked a previous question regarding styling radio buttons and giving a border color like you can do with text boxes, example:
<input type="text" style="border-color:#FF0000">
<input type="radio" style="border-color:#FF0000">
applying style to a radio button to change the border color does not work.
My Question is there any reason why I shouldnt use a drop down list insead of a radio group?
Drop down lists require more work (on the part of the user) to find out what options are available … and are as twiddly to style as radio buttons anyway.
You might try setting the border colour on the fieldset containing the radio group instead. Remember to also use some other method for indicating required fields though.
A radio group will take more room on your form than a drop down list, and of course the controls look different in appearance. My rule of thumb is if there are more than three or four choices, use a drop down list.
Majority of the users (includes mostly people with no computer background and elderly people) are really very familiar with radio buttons to answer questions of the type yes/no , male/female etc. For the convenience of the users use a radio button for such questions.
With Drop down lists the available options are not visible to the user until they interact (click it). With radio buttons all of the available options are in front of the user. While both allow you to limit the selection choices to just one option, I find that users can decide which option they want quicker with radio buttons. If it is more than 5 options though, I would reconsider.
Related question on ux.stackexchange.
Use a drop-down list for when one choice is regarded as "more important" and the alternatives are okay as being hidden from the user, for example, selecting a state in the U.S. A user lives in one state, and the alternative choices don't matter. When the user comes to the form item, they know exactly what to choose without looking at the alternatives.
On the other hand, use radio buttons for when the choices are all equally important, or the user needs to see all of them before making a selection, for example, rating on a scale from 1 to 5, or choosing an answer choice on a multiple-choice problem.
Another factor to take into account is screen real-estate: you wouldn't want radio buttons for selecting one of 50 states, and you probably wouldn't want a drop-down list for selecting a sex (Male or Female). Depending on your design and philosophy, this factor may or may not trump the factors stated above.
Related
I have a page with many buttons labelled "Buy". How can I make them unique? They aren't in a form.
Thanks
This message basically means that you must provide more precise context in the text of your buttons, because you have at least two of them with the same accessible text and they are so undistinguishable one from the other.
When using a screen reader, depending on how do you navigate, you jump directly to a given element, but skip over the elements that can give you more context.
In your case, for example, if I navigate by from button to button, I would be jumping from one "buy" button to the next, without being told what I'm going to buy because the information isn't on the button itself but next to it.
So it's absolutly required to give me more context, by extending the text of the buttons. The text in question isn't required to be visible on the screen, as it's a specific screen reader issue.
However, other people may also benefit from it if the text is also available as tooltip for example.
There are several ways to add the required context to your buttons.
The simplest is probably to use screen reader specific text also known as visually hidden text, like this:
<button>Buy<span class="sr_only"> basic package for 10$</span></button>
<button>Buy<span class="sr_only"> premium package for 20$</span></button>
<button>Buy<span class="sr_only"> full package for 40$</span></button>
Where .sr_only is a specific class from bootstrap. Other frameworks have similar CSS classes doing the same.
Pay attention to spacing so that words aren't uselessly glued together.
You may also use aria-label, like this:
<button aria-label="Buy basic package for 10$">Buy</button>
<button aria-label="Buy premium package for 20$">Buy</button>
<button aria-label="Buy full package for 40$">Buy</button>
Having the extended text in another element is also possible with aria-labelledby.
For both aria-label and aria-labelledby, in the label, pay attention to repeat the text actually shown on the button, as the accessible label completely replaces the natural text of the button (here, repeat the word "buy").
As a final note, it's also a good practice to shortly remind of the price, like I did here.
Depending on what you are selling, telling about the price late in the buying process (like just before checkout) can be considered as a dark pattern, and it's even more true with screen reader users, as they may miss indications that are obvious for sighted people.
There are many ways. Hopefully each button has a unique ID and so does something on the page containing text describing what the user would be buying. Then you can use the aria-labelledby attribute:
<button id="unique-thing-to-buy-button" aria-labelledby="unique-thing-to-buy-button unique-thing-to-buy">Buy</button>
Note that the ID's are space separated. This will announce the word buy followed buy the thing we are buying in a screen reader.
If not, you can create a translated string that accomplishes the same thing and use aria-label.
<button aria-label="buy unique thing">Buy</button>
Optimally, you would have something to improve the experience for sighted users as well. Putting a similar string in the title attribute to display on hover is a good start. Ideally you would use a widget that displays the same string on focus to cover your non-mouse users.
What's the semantic difference between using a <select> element containing <option> children and, using an <input type="radio"> elements within a <fieldset> parent? Both methods offer the user to select at most one option. The only differences are visual and user-experience-related: the first method shows the user a drop-down menu while the other option shows radio buttons.
Equivalently, what's the difference between <select multiple=""> with <option> children (a select-multiple drop-down) and using <input type="checkbox"> (check boxes)? Again, I don't see any difference in function; only presentation.
I'm just wondering why the HTML spec has both methods for developers to use. If the only difference is in the presentation and in the user experience, shouldn't we only be using one method?
In general terminology there is no such particular difference between Radio Button and a Select List(Dropdown) but, since the screen space used is proportional to the number of options, if the number of options are between two to seven a web designer goes for using radio buttons, for eight or more options, he/she uses a drop-down list or single-selection list.
Another thing to keep in mind while designing is: If the default option is recommended for most users in most situations, radio buttons might draw more attention to the options than necessary.
Consider using a drop-down list if you don't want to draw attention to the options, or you don't want to encourage users to make changes. A drop-down list focuses on the current selection, whereas radio buttons emphasize all options equally.
The same follows for the checkbox and multiselect dropdown.
I have a tree of data organized like so (but with many many more options) in a dropdown list:
pizza
pizza.mediterranean
pizza.veggie
pizza.meatlover
drinks
drinks.soda
drinks.soda.pepsi
drinks.soda.coke
drinks.beer
drinks.water
I want the larger categories (pizza,drinks) to show up as optgroups but I want to be able to select an optgroup as an option in the drop down list. What I have read multiple places is that optgroups are only for grouping and can not be selected.
Since I also want more than one level of indentation to allow the dropdown to look as close to the above example as possible -- perhaps optgroups aren't the way to go but rather a css solution. In firefox I can do what I want by adding styles to the options and making them bold and/or have a left padding but it seems like in webkit the only attibute I can change on options in a dropdown is their color.
Does anyone know how I can achieve this effect in webkit (chrome/safari) and firefox --- (I don't really care about IE at the moment) using optgroups, css, or anything else?
You may just want to go low-tech:
<select>
<option>Root</option>
<option> Second level</option>
<option> Third level</option>
</select>
You are hitting the limits of what you can do with a real select. Conceptually, these select widgets are drawn by the OS (although some browsers - firefox - have their own implementations), so the styling options are limited.
There are many nice select replacements. The one I'm most familiar with is jqueryui's autocomplete. It is fast and flexible and you can style the options however you like. One can imagine other home-grown solutions using jquery or another toolkit - or plain 'ol javascript.
Using a set of radio buttons (or checkboxes, if several choices are to be allowed) instead of a select element, you can organize and style them like any other content, e.g. with indentation and bolding. It won’t act as a dropdown menu, though, but this can actually be a usability and accessibility improvement.
I have several Radio Button lists on my page, each lists items under different categories, so they are listed under different headings.
I only want one item to be selected across all the lists however.
Is it possible to "group" the lists so that the affectively behave as one RadioButton Lists?
I want to avoid using jQuery/Javascript if possible
Not using the standard ASP.Net radio button list control I believe. The best thing to do would be to render out your radio buttons one-by-one in their individual lists and of course, set the "name" property so they all belong to the same group.
You could also (depending on the structure of your data) just render all options in one radio button list control and then use the css nth child selectors to insert divs/line breaks/etc. But you would probably need jQuery for this unless your targeting only browsers that supports CSS3.
I have a shipping form. Three input fields surround the shipping address.
Below are the labels (and in parenthesis their "for" values)
1) Address/P.O. Box (for="shipAddress1")
2) Address 2 (for="shipAddress2")
3) Use for International Address only(for="shipAddress3")
Our designer has proposed to label them simple as "Street Address or P/O Box", but I still want to present these 3 labels for Web Accessibility (right?).
What should I do with items 1, 2, & 3 above -- should I apply a text-indent:-1000em; or something like that. I'm assuming using display:none mean screen reader can't see them also, right?
Thoughts?
Do you need to show the labels to the user or not? If not, use text-indent:-999px to position them off the page. Display:none will not be picked up by screen readers.
This is a good overview on positioning rather than hiding for accessibility: http://www.nickfitz.co.uk/2007/02/14/why-left-9999px-is-better-for-accessibility-than-display-none/
Still, I'm not entirely sure what you need to show your users. Your question is a bit confusing.
As I understand you have three field, only one or two can be filled.
Why not ask the user to choose which filed is filled with an option.
Nicolas