Excuse me for the maybe very stupid question, but my curiosity is killing me, and plus I'm new to this, but are using labels important in your markup, and why?
i.e.
<label for="birthdate">Birthdate:</label>
<input type="text" id="birthdate" name="birthdate" />
Why must I label this input, why is it beneficial to the user, why is going to be beneficial for future use, or is it search engine optimization thing. That's what I really wanna know :)
It's important for a number of reasons:
Clicking the label focuses on the
text field, which is something a lot
of users expect.
It's helpful for the accessibility reasons.
How else is the user going to know which field is which? You could use
just text or a span or something, but
why would you?
It leads to a more semantic markup.
It helps for accessibility, e.g. screen-readers.
Also for things like checkboxes it allows the user to click on the label and not just the checkbox itself (Try it!).
It's important for accessibility, so blind people using screen readers can easily tell which text box is meant for which thing, since possibly otherwise their software cannot tell the purpose of the active text box from the page structure. Also, clicking on the label will focus the appropriate input control, which is convenient.
Future use:
In a case where the input html form is directly linked with database ( happens in frameworks)
so the input form variables directly represent database columns.
So, instead of showing database column names to the user in the form, we can show simplified names to the user using Labels.
Related
I'm trying to find a way to make screen readers like NVDA of Windows Narrator stop reading an input value and read the aria-describedby only instead.
Here's the case, I have a web component that is a mask-input field. Let's say it is configured with a phone mask set to (___) ___-____ where underscore can only be numbers. Right now the screen reader would read left parens, 3 lines, right parens, space... and so on and then read what I set as the aria-describedby value which would be something like "Phone number, 1231231234" which use the unmasked value of my component.
What I'd like, would be the screen reader to only say "Phone number, 1231231234" which is my aria-describedby value and skip the rest so it keeps short and avoid saying things that can confused impaired user..
A bit of background, maybe this can change a bit the response, my component is built with Aurelia, I'm leveraging the binding system to update the value.
Is this something possible? I there a few alternative? I'm I completely off-track with what I'm trying to achieve?
Thanks!
There isn't a lot you can do to maintain accessibility with this approach. It is very important for the screen reader to read out the contents of the input field, otherwise when a user types a number it will not tell them what that number is - also if they decide to go back a character or forward a character, the value will read the label and not something they've entered. I imagine the input mask you're using is using javascript to replace a masked character with the user submitted one on keypress?
It is generally best practice to outline what the required input format is in the label or in descriptive text associated with the label. This will allow sighted users to easily match the required format and also allow visually disabled users to use their keyboard to navigate the input value with full knowledge of what the desired format is. I've thrown together a quick example of this.
<label for="textInput">Phone Number</label>
<span id="phoneDesc">Please use the following format: (xxx)xxx-xxxx</span>
<input id="textInput" type="text" aria-describedby="phoneDesc" />
It could also be helpful to look into the general usability of input masks - a lot of people tend to find them troublesome.
https://www.nngroup.com/articles/stop-password-masking/
If you're determined to use them and don't mind a different approach from your 'line' based approach, maybe give politespace a try (I have not tried this, but it could be worth evaluating for your needs)
https://github.com/filamentgroup/politespace
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'm working on a Web-GUI for a semantic search with a single text-input as a search-box. Typical queries are: "buildings higher than 100 meters".
I want to format the input text as the server answers the question. The entities and operators should be colored to make it easier for the user to see what the computer understood.
Example:
I found thousands of hacks out there to accomplish this, but all of them were really awkward to some degree. I still want it to feel like a text-field. I want the user to be able to move the cursor by clicking and using the key-arrows. While querying the server, the text should of course be black only. The coloring comes from the servers interpretation and ususally is available "as-you-type" (few milliseconds answer-time).
I want this thread to be a discussion of the different possibilities of accomplishing this task and find the best general-purpose solution for everybody.
Perhaps a possible solution would be for you to use an editable div, like below:
<div contentEditable="true">
Lorem <b>ipsum</b> dolor
</div>
This way you can able to style user input as user type in (may be on keyUp event). While you submit this value in a form, you'll have to use JavaScript to get the innerHTML of this div and assign it to a hidden input or something.
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>.
There are several hidden form fields on my pages that are used for passing data to server side. For debugging purposes, I feel it easier to hide all eligible input fields by just making them all a part of hidden class than setting the type=hidden attribute on each input field.
Whenever I need to debug I could easily modify that class attribute to enter debug mode. Ofcourse both the approaches work in hiding the input fields but I am not sure as to why this approach(hiding via class) isn't much widely used in real life. Can you throw some light on what should be preferred approach ?
<input type="hidden"> won't trigger input validation, auto completion, and other user interaction related events. It's designed to save raw data, without user's direct input.
But a <input type="text">, visually hidden, are still going to be considered as a user interaction component. And on some devices enabled visual aid, it will serve as not hidden, and cannot provide the consistency you expected. That's why it's not preferred to do so.
Eg. a <input type="hidden"> won't auto complete it self, or preserve the inputted data before refreshing a page, or prevent the form from being submitted for a failed type validation can't even be seen.
The CSS approach is bad for usability, and accessibility. Think of someone with CSS disabled (very old mobile phones, people with a screen reader), they won't render your CSS as you might expect, and the input with all of its glory would be displayed to the user.
A hidden input should be used for implied user input, meaning, input that would come from the user, but is implied and does not need to be manually entered.
Your question falls more onto the type="hidden" approach.
I'd recommend using <input type="hidden" /> because it is the standard way of HTML to hold a user's input value. If you use another attribute for type and hide it with css, one problem may arise is that when the css fails to load, the input control will show up.
I think your question is about the best approach for debugging form fields. I recommend keeping them as type='hidden' in your HTML. This is best for you, for your users and for semantic interpretation of the page.
Instead, use a tool like the Chrome Developer Tools to do your debugging. This will let you easily see the values of your hidden fields.