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
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.
The Problem in Hand:
I want to make a form designer where user can drag and drop fields of different type and design the layout too, some what similar to wufoo form builder but here the layout is limited to single column whereas I want to make something where user can make the layout as they want.
I understand how to do in single column view, but could not understand how to achieve multiple column layout eg: row 1 there could be 3 elements, row 2 one element stretched to full length, row 3 there could be just 2 elements etc.
What I tried:
I have tried with jquery UI sortable to make a single column layout with using div where new elements can be dragged and repositioned.
Any suggestion on how to proceed further will be helpful
I have tried searching StackOverFlow and google but could not find any link on a similar topic. If anyone could point me to the same, it will be also helpful.
When you reorder elements on wufoo form builder, you can only drag'n'drop up or down. Remove that restriction and as soon as one element is dragged across a certain threshold, it "belongs" to the next column. If the "old" column was the first or last one and the line that the element was moved over was to the "outside" of the form, add a new column there, until the maximal number of columns is reached.
If the used drags the last element of a column into another column, remove the now empty column on element-drop.
You could also remove the dynamic adding/removing of columns and juist have a button ("remove column" & "add column") to do it by code.
An example for the dropping in another column can be found here: http://jqueryui.com/sortable/#connect-lists
Hope this helped!
Edit:
http://jqueryui.com/sortable/#portlets and http://jqueryui.com/sortable/#empty-lists also have elements that you could look into. Good luck! Sounds like a nice project. Can we see any progress or beta?
simply put, i think that the input 'size' field is now obsolete (like the rest of html styling outside of css), and most of the sizing attributes have been deprecated, so why not input.size?
Maybe you got confused between size and width/height attributes (btw I got confused at first when you said field). But assuming you didn't, let me explain what size is for.
size attribute
The attribute size for element <input> applies to text inputs, like e-mail, password, etc. It defines the maximum character width for the input. Let's say for example you want the maximum password length to be 4 to screw the users, you give it size=4, so you cannot enter passwords like dinosaur (anything you type after dino will not appear unless you delete the previous letters first)
Edit: as pointed out by Maksym in the comments, the above is defined by maxwidth, not size. size is, if we refer to HTML4 spec,
except when type attribute has the value "text" or "password". In that case, its value refers to the (integer) number of characters.
So size=4 is about 4 (monospaced?) characters wide (My experiment with Google Chrome has makes it size+1 though, i.e. size=4 is 5 characters wide.)
Dimension attributes
Now in case of the dimension attributes width and height. For <input> elements, they apply only to image buttons. They define the dimensions of the button. Now why can't you just apply CSS to them?
First, know that CSS is for visual purposes. Image buttons submit coordinates that the user clicked on. This behavior needs to be consistent across browsers, whether they support CSS or not. See this warped image:
There may be a case where the user is asked to click the letter e for the form submit to be processed differently. Probably the server will check whether the x coordinate is 75 <= x <= 90. But if you defined the dimension with CSS, browsers which disabled CSS will see this image instead:
And the previous coordinate range check is no longer valid, seeing that the letter e is further to the right, hardly within 75 and 90 (and you need to click on the left side of the first o to get the same input).
That is a rhetorical question really... or an attempt at persuasive argument. You are right, though-- it could easily be deprecated and CSS take over. As for why, that answer can only come from someone inside W3C who is part of the decision making process. You could also ask why cellpadding, cellspacing, and width properties are not deprecated in tables.
The best answer I can give you to your non-question is that HTML isn't a purist language--while it's getting back to it's roots of being just content and not style or behavior, it still has it's legacy from the 90's and 00's, which means it still has concerns beyond just content.
There's a valid reason why this attribute isn't deprecated: "Web Usability"
When a user views your site, considering the CSS is turned of or unavailable, it's really a bad idea to let the person see a long field while in fact, the field only requires a few characters (such as ids, phone numbers, etc.).
CSS is good, yes, but only if you also considered people who won't be able to use them.
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.
I have a bunch of elements (divs) and they represent items. I can delete them by clicking a link and its done through ajax. I had the divs store the value in id however it appears that even though it does work the standard says id names must start with a letter. So i could start it with a letter and remove it when i use ajax or i can store the value another way.
What are ways i can store values in html? I don't think inputs are legal outside of forms but i am rethinking what are good ways to store values.
Best way is to use the new HTML 5 spec to store data in the data-[name] in the div elements
ie
<div data-yourfield="value">
Text
</div>
Then using jQuery find the divs with the selector (reference http://api.jquery.com/category/selectors/)
div[data-yourField=""]
You can store it as text inside the div if you like. You also can use inputs, just add the form tag around everything. Just because it's a form doesn't mean it has to "submit". Inputs or textboxes would probably be the best way to store them actually.