I was recently working on styling forms. It is much harder to style the elements of the forms like for example: input, select, checkbox or radio button as it seems they are controlled by operating system (right?) And don't respond very well to CSS3.
So I went to youtube and took a look how they deal with checkboxes (for example when you add a song to one of your playlists) and... boom! they don't use checkboxes at all, instead they build everything with div elements.
So my question is: is to a common practices? It seems that it gives a lot of more freedom of how one could style the checkboxes. How about other form elements? It's really annoying that default form elements are not editable well with CSS.
Related
I am creating a search form that has two elements an input field and a button. The input field does not have an label associated with it.
To make the field more accessible I can add <label for="searchfield">Search</label> and visually hide it so it will e.g. be accessible for screenreaders.
I could also add aria-label="search" to the input field and leave the input field without an label.
I have tested with "Voice Over" on a Mac and I get the same result/output. My question is are these approaches equivalent? Or is one approach better than the other one?
Here is a pen.
In the absence of having any knowledge of the site (how are other form fields labeled?) or the audience (what is their skill level or tech profile?), I approach these questions with a couple parameters:
The rules of ARIA (the first rule may apply here)
Progressive enhancement
That being said, I often code a page without ARIA and without CSS (as that may get blocked, chunked, etc) and make sure it is accessible.
That means I code a <label>. Then I visually hide it. If the CSS breaks, all is still well. If the user's screen reader does not support ARIA, all is still well. As an aside, if you think all screen readers of your users support ARIA, I encourage you to do to a tech assessment of users (local blind associations are a good start in the absence of any real users). Many people still run older versions of browsers and SRs.
For sighted users, I make sure I lean on contextual clues, like a clear search icon (or the word) in the button (as Unor references). Or maybe a placeholder with appropriate contrast (though you could use the <label> as a visual placeholder with some CSS trickery to hide it on focus).
If your submit button uses SVG, then I would be folding ARIA into that given the inconsistent support around SVG alternative text methods.
FWIW, I am also not a fan of the title attribute, partly because of inconsistent accessible name calculation and partly because I think it looks meh.
So, to answer your questions:
My question is are these approaches equivalent?
No, but the distance between them is shrinking.
Or is one approach better than the other one?
That depends on context we do not have.
Using aria-label is preferable to relying on CSS to visually hide a label element.
(Related Technique: Using aria-label to provide an invisible label where a visible label cannot be used)
But note that you don’t have to provide a label for a search form that only consists of the search field and the submit button. Assuming that you use a button labeled with something like "Search", it already makes clear which purpose the text field has.
(Related Technique: Using an adjacent button to label the purpose of a field)
In that case, while it doesn’t need a label, it should still get a name. One way to provide a name is to use the title attribute on the input element. The Technique Using the title attribute to identify form controls when the label element cannot be used shows this (a search form without label, with title attribute on input) in example 3.
I believe that aria-label="search" is the correct approach, as it produces cleaner markup (i.e. no unnecessary label tag) and no need for CSS to set visibility of the label - like in this example.
I believe visually hiding a label using CSS is a somewhat 'hacky' way to approach the problem, whereas ARIA is the standard for accessible markup, so it should be the obvious choice for situations like this.
On the other hand, it would be worth ensuring all browsers you intend to support can use ARIA correctly, and if not, it may be worth using the label approach to ensure compatibility across all browsers. Although, I think the support these days is pretty good, so that should not be a common scenario.
I just read this post about the term "control" when dealing with forms.
However, the OP asked it in relation to Bootstrap, and I'd like know if this term has a general definition, and more importantly: Does its usage relates only to web forms, or does it have more usages in web development?
Typically, a "control" is a UI element which causes some action to occur. For example, both text inputs and submit buttons are examples of "control" UI elements.
There are special control elements implemented by specific frameworks or platform ecosystems. For example, there are many variations on calendar UI element controls.
Form controls are those elements (which you use in conjunction with a form) that the user interacts with directly. Examples include text boxes, drop down menus and buttons.
From the specification:
A form is a component of a Web page that has form controls, such as text fields, buttons, checkboxes, range controls, or color pickers.
and
Most controls are represented by the input element, which by default provides a one-line text field.
My question stems from the context of a web application, rather than a web page. In that context it often does not make any sense to submitt data. You want to modify state in your application using controls.
To me, it then does not make any sense to use a form. However I still need controls/widgets to modify. Meaning I need tags such as input, which I understand is a "form control", indicating that they should always be contained inside a form. Furthermore I want to organize my controls in fieldset tags.
So I was left wondering if I now have to wrap all of my controls in form-tags, even though this to me seems symantically incorrect (since I'm not going to submit).
After a few quick searches I found the two following two breif forum discussions on topic:
http://www.webmasterworld.com/forum21/8837.htm
http://doctype.com/can-fieldset-outside-form
To sum them up, using form controls outside of a form will validate on w3c. However rendering might not work in really old browsers (like Netscape 4, which I really don't care about.)
In the first link there seems to be support for using form controls outside of forms as the symantically correct thing to do in my sort of scenario. However in the other it seems that using fieldsets should strictly be done within a form when caring about being symantically correct.
Does this mean I should feel free to use controls outside of forms, but I must wrap them in divs rather than fieldsets, or should I read this some other way?
The w3c states:
17.2.1 Control types
The elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces. This is discussed in the section on intrinsic events. Note that controls outside a form cannot be successful controls.
17.10 Adding structure to forms: the FIELDSET and LEGEND elements
The FIELDSET element allows authors to group thematically related controls and labels.
17.10 doesn't make any mention of the form element, to me this means that there is no limitation on where it can be used except that it should surround controls and labels. 17.10.2 Seems to allow me to use those outside of a form. Hence I can also use the fieldset outside of a form, as long as it wraps controls and labels.
I have come across use cases where I have required to have form controls without the need for actually submitting the form.
Sometimes, enclosing within the tag only makes the things worse, because I might be interested in calling a JS function whereas the form simply submits and reloads the page. I have encountered this using PhoneGap application on a WindowsPhone.
As for me, I wouldn't be too bothered about W3C validation, given it makes life much more simpler.
I'm upgrading the HTML for a site, and there is currently a list of items presented as filters or refinements that are marked up as check-boxes with labels, but not in a form. Then for "SEO reasons" they added an <a /> tag that isn't wrapped around it:
<label>
<input type="checkbox" name="one" value="one" /> Refinement One
</label>
This is obviously not really adding full SEO value, and its kind of clunky HTML since the checkbox isn't necessary: the page works by listening for clicks on the label and firing an ajax load, all without a form. To be clear: there is no form, let alone a form submission, so the checkbox is there only as a visual cue. I want to replace it with background images on the anchor, and ditch the checkbox completely like the following:
Refinement One
<a class="checked" href="/url-for-adding-two">Refinement Two</a>
The client is cool with this, but their main concern is with accessibility and how this change would be reflected to screen readers... my personal thought is that it must be better than checkboxes without a form, but I want a better answer that my gut-check.
Do you know of any accessibility implications of replacing checkboxes with links in this situation?
If the page works by listening to clicks, then it in principle violates the accessibility requirement “Make all functionality available from a keyboard”. In practice, though, pressing Enter key in a focused element is generally treated as corresponding to clicking, i.e. a click event is triggered.
Checkboxes without a form are not a problem as such, never were. They can only work via client-side scripting, of course.
Using links might be related to history bookkeeping rather than SEO (because pages referred this way are seldom relevant in searches). If they are desired, then the choice is between making the control a link and duplicating it with a link. Duplication may cause confusion, especially in unusual browsing situations, so the link approach appears to be better. If the purpose of the link is to cause some action immediately, then it might be better to style it to look like a button. So a checkbox, even as a pure graphic, would appear to be unnecessary.
If it is necessary to show the user the options that have been taken (similarly to showing a checked checkbox), this could be done e.g. by showing a list of currently selected options (possibly along with buttons for unselecting).
The question is whether they end up looking like and behaving like checkboxes to sighted users. If these are items that visually appear to have a checked / unchecked state, and can have that state toggled by clicking, then they are behaving as checkboxes, so need to be exposed as such to screenreader users.
The problem with using plain anchors here is that the screenreader will just read them out as link elements, so a screenreader user will be expecting navigation to take place, not something that toggles state on a page. Also, no checked state information will be read out, so a screenreader user won't know if the item is checked or not.
The ideal situation here is to continue using real checkboxes, as in the original code. (Drop the empty A tag; it's a problem for keyboard users, as they can tab into it, but it has no screen presence - for sighted keyboard users - and has no content text, so screenreaders will just read out "link" leaving the user confused about what the focus is on.)
The advantages of using real input type=checkbox controls here is that they just work; sighted mouse users, sighted keyboard users and screenreader users all get good experiences. They are mouse and keyboard accessible; screenreaders will announce them as checkboxes, and convey the checked/unchecked state. (It doesn't matter that they are not in an actual HTML form.)
--
For what it's worth, if you did have some compelling reason to not use input type=checkbox and instead had to use an A that has been modified with click handlers and background images to behave as though it were a checkbox - and I don't think there's a good reason for going that route here! - then you could use the WAI-ARIA attributes to mark up the control with additional semantic hints so that screenreaders will announce it as a checkbox with correct state; this would involve adding role="checkbox" and aria-checked="true", for example. Also, since users expect checkboxes to respond to the spacebar as well as enter, you'd need to add keyboard handling for that also. And you'd need to test this with a screenreader to make sure it actually works. That's a lot of work to duplicate what input already does for you! This approach, however, does make sense when implementing custom controls that HTML does not already provide handy equivalents for, such as menus, sliders, treeviews and the like. Some of these will eventually - or are already - making their way into HTML anyhow.)
The correct answer here is to use ARIA, in particular the aria-checked attribute. It's designed specifically for accessibility.
That said, I think your desire to get rid of the checkboxes is misguided. Anything that acts like a checkbox---i.e., it has a checked state and an unchecked state, which controls something on the page---should probably be a real checkbox. This gives you very nice behavior in terms of not only screenreaders, but also what keyboard and mouse users expect.
You can always wrap the <a> around the <label>.
On many websites, when typing in a username for example, a dropdown occurs where previous input shows up so the user can easily select something instead of typing. I know you can turn this off in browsers by having the form or input have an attribute of autocomplete="off". The problem is when I want it on, and the input has padding. The dropdown looks horribly off because it has no padding for each item.
Is there any way to style this with only css? I'm aware that you could potentially use a javascript/jQuery workaround to store previous entries in a cookie or something and make your own dropdown. But I don't want to rely on javascript for this.
Nope. Autocomplete is not a part of any standard, and is not part of the DOM. The only way to style is, as you've suggested yourself, by recreating that functionality using JavaScript.
Unfortunately there is no way to style the drop down box itself with CSS, because in this case (when not using javascript/jQuery/mootools/etc.) it is operating system dependent - i.e Windows/Linux/Mas OS visualize it according the visual user settings (i.e scheme).