Forms

A quick reminder on how and why to use labels in forms to make them more accessible

Yesterday the excellent Alice Boxhall of the Google Chrome team pointed out an annoying bug to me:

Seen in the wild on https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer … <label for="tos-checkbox"><input type="checkbox" name="tos-checkbox">I agree</label> @codepo8

It seems the UserVoice page of Microsoft Edge has a checkbox that is inaccessible to screen reader users. The reason is a wrong implementation of a label. So, here is a quick reminder of how to use labels in plain HTML (without any ARIA extras) and why that’s a good idea.

Labels are there to connect an explanatory text with a form element. For a sighted user this can seem redundant – after all, the text is right next to the element. But once you use a screen reader you see that by not using labels, you make it impossible for people to use your forms.

The markup used in this demo is the following:

<div>
  <input type="checkbox" name="wombat"> 
  Yes, I want to buy a wombat!
</div>
<div>
  <label>
    <input type="checkbox" name="quokka">
    Yes, I want to buy a quokka!
  </label>
</div>
<div>
  <input type="checkbox" id="yayforwallaby" 
         name="wallaby">
  <label for="yayforwallaby">
    Yes, I want to buy a wallaby!
  </label>
</div>

On my Mac, using the in-built VoiceOver and Firefox, it is easy to test. Simply turn on VoiceOver Command+Fn+F5 and navigate using your keyboard by tabbing into the document. Here’s what that looks and sounds like:

In addition to the benefits for screenreaders, labels also make it easier for mouse or touch users to interact with your content. The following GIF shows that the options having labels enable the user to either click the tiny checkbox or the much larger text to check and uncheck.

showing how checkboxes with labels make the text clickable

Using labels isn’t hard. The simplest way is to nest the form element and the text inside the label:

  <label>
    <input type="checkbox" name="quokka">
    Yes, I want to buy a quokka!
  </label>

If you can’t do that, you need to connect the label and the form element using a for/id pairing. Remember, a form element’s id has no meaning to the form. The data sent to the server is what’s defined in the name attribute. The id is only good for scripting, CSS and as a fragment identifier/anchor. The following example shows how to connect the form element and the label:

<input type="checkbox" id="yayforwallaby" 
       name="wallaby">
<label for="yayforwallaby">
  Yes, I want to buy a wallaby!
</label>

This is what’s broken in the UserVoice example: there is a for attribute on the label, but the form element has no id. Hence there is no connection between the two and the label becomes redundant.

Quick aside: if you wanted to write a test for that, remember that the for attribute in HTML elements can not be accessed as element.for as for is a reserved word. It needs to be htmlFor.

As a way to catch the mistake in the sign-up form, you could do the following:

var labels = document.querySelectorAll('label');
for (var i=0; i<labels.length; i++) {
  if (labels[i].htmlFor) {
    if (!document.getElementById(labels[i].htmlFor)) {
      labels[i].style.background = 'firebrick';
    }
  }
}

Now, go forth and label the web!

Updates

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HTML 5 Forms

By Mark DuBois
Director of Education

Details, details, details

 

It is April, 2015 as I write this post. HTML5 is supported by the majority of modern browsers. HTML5 contains a lot of semantic markup. For those who don’t know – semantic markup means that the HTML markup reinforces the meaning of the information on the web page. Yes, I often encounter pages written in an antiquated view of HTML. As a web designer or developer, I would think we should take advantage of these capabilities as often as possible/ practical. It doesn’t take more than a few moments when developing a page.

Permit me to provide a simple example. I often complete forms on my smartphone. I can’t count the number of times I have to use additional keys because someone who designed the form I am trying to complete had no understanding of the capabilities of HTML5. For example, one can code for a text input element which contains email. One can code this in multiple ways. Given this is 2015, I think the appropriate attribute should be type=”email” instead of type=”text” (and here is why).

I created two very simple forms. In the first example, I chose to use a semantic attribute. Note how the phone keyboard automatically detected that and provided a keyboard with the @ symbol included (very handy when entering an email address)

mark dubois form image

 

 

 

 

However, many forms I encounter use the older approach of type=”text” (note the keyboard which then pops up). I now have to tap another key (123) to get to the @ symbol. This is an extra step. It slows me down. I personally find it frustrating. Beyond that, search engines won’t know this input field is for email addresses.

Yes, this is a ridiculously simple example. I did this for a couple of reasons.
First, we are in the middle of a number of web design contests. Aspiring professionals should be developing good habits and practices. They should know all the semantic features of HTML5 and employ them where appropriate.
Second, we should all be taking advantages of these improvements. If we want our web page rank to increase on search engines, our pages should validate. Our pages should use semantic markup and so forth. It takes typing 1 extra character to use proper markup for the input field in question (is it really all that difficult to type email instead of text)?

As always, I look forward to your comments.

The post HTML 5 Forms appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Before you try to “fix” or “improve” forms on the web…

…it is prudent to think of a few things:

  • Forms are incredibly important for the web. People enter data into them and the data goes to a server (via HTTP and a page reload, into a frame, or via XHR).
  • Entering forms is annoying and frustrating as in many cases you need to look up data elsewhere (your credit card number, itinerary numbers…). This is why you main goal should be to create a working form that needs the least amount of information labeled in an understandable fashion. The look of the form is less important than that – this pleases us and our clients but a pretty form that isn’t understandable is not good for your users
  • A form that points nowhere is not a form. Have an action attribute that points to a server-side script and a submit button to enable sending the form by hitting enter. If and when there is a JS error, people can still send the data which is what you want.
  • Label elements are incredibly important. They tell assistive technology what a certain input element is and they allow users to click the label instead of clicking on the small checkbox. This is very important on touch devices (ever tried to check-in at the British Airways boarding pass on your phone? The checkbox is under a link. Guess what I click in 99% of the cases). There are two ways to connect input elements and labels:
    • You can just embed the input in the label:

      <label>Your web site 
      <input placeholder="http://example.com" 
      type="url">
      </label>
    • Or you can connect them with a for/ID:

      <input type="checkbox" id="uni">
      <label for="uni">Add unicorns?</label>
  • Every input element needs a label (arguably the submit button doesn’t – if you have an action forms can be sent by hitting enter), this can be annoying with radio boxes, but you want them to be understandable, don’t you? Also, adding a label gives you a handle to create elements with CSS using ::before and ::after. As input elements are replaced elements that doesn’t work on them.
  • Labels without for attributes or input elements in them are pointless.
  • If you replace input element with your own styled elements (using image replacement techniques) think of the following:
    • What happens when the image/icon font can’t be loaded?
    • How does it look when you zoom into the page?
    • Is there enough contrast to the background and is it obvious that this is an input element?

It is very easy to replace forms with “nicer” things. It is also too easy to block out a lot of users when you do.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

headtrackr for real-time face tracking, smartphone features you never thought of, HTML5 Forms support + more in Hacks Weekly

This week Mozilla’s Developer Engagement team suggest reading about headtrackr for real-time face tracking, smartphone features you never thought of using, Web browser support for HTML5 Forms and more!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)