Now that you have a handle on the basics of structuring content for an HTML file:
- Let’s discuss building more robust HTML forms
- Let’s start using our devtools
- Let’s put accessibility best practices into place
HTML Guide and form structure
Forms are an important part of a website. They allow users to send data to the web site. Most of the time that data is sent to the web server, but the web page can also intercept it to use it on its own. Forms are comprised of the following base elements:
Your Challenges (2)
Partner up and answer the following questions:
- What is the attribute
forindicate on the
labelelement? Do you always have to use it? Why or why not?
- What are 5 values for the
typeattribute of an
inputelement and how do they work?
- What is the significance of the
nameattribute in a form?
- What is a
- Why would a
legendelement be important?
Copy the form code below into your own Pen, and then refactor as follows:
- Validate for email type
- Add a set of radio buttons with at least three options - only allowing one to be selected at a time
- Include placeholders for name, email, and message
- Add a drop down for favorite color with at least three options
- Use an input for submit instead of a button
Chrome Dev Tools
Debugging your front-end code can be an intimidating part of the development process, but it’s also one of the most powerful skills you can acquire Developers of all levels spend a significant amount of time troubleshooting code, but the more comfortable you are with debugging tools, the easier it will be to isolate, identify and fix broken code.
Take 5 minutes to read through this section of the chrome devtools docs.
One of the first tools you should familiarize yourself with when doing front-end development are the built-in browser DevTools. To open developer tools in Chrome:
- (or) Right click on the browser window and select
- (or) Select
Viewin the navbar, then
Personally I find that pinning the dev tools to the upper right is the most convenient. (You can also expand them into their own window.)
Once you have your DevTools window open, you’ll notice a toolbar across the top with several different tabs. Clicking on these tabs will bring you to different debugging panels, each built to help troubleshoot specific areas of your front-end code.
As mentioned earlier, there are a lot of places on the front-end where code can go wrong. This means the first and most important step in solving a bug is isolating the problem. DevTools has already done some of this step for us by categorizing the most commmon areas where developers run into problems, and providing us with specific debugging panels for each.
For now, we’re only going to focus on the first panel: Elements.
The Elements Panel: Debugging HTML, CSS & DOM Events
- debugging layout and styling issues
- checking DOM Events
The elements panel lets you view the entire HTML source of the current page you are viewing. From here, you can edit, add or remove content and elements directly on the page. Though your changes won’t be saved (any changes made here will be lost upon refreshing the page), sometimes it’s helpful to make tweaks directly in this panel so you can see what effect the changes will have on your application before you implement them.
Selecting Elements to work with
You’ll notice hovering over an HTML element in the devtools panel will also highlight that element on the page. This makes it easier to find and select the content you’d like to work with.
You can also select elements directly on the page by clicking the icon in the toolbar, then hovering over the element on the page. This will automatically bring you to the corresponding code for that element in the devtools panel.
If you’re having trouble finding the element you’d like to work with, you can search through the entire HTML with
Cmd + F. You’ll notice a searchbar appear at the bottom of the panel where you can enter any string to find a match. This is useful if you’d like to search for an element by a known ID or class.
Directly from the elements panel, we can edit the HTML and see the changes reflected immediately. (Again, these changes won’t be saved to your codebase, but sometimes it helps to see the tweaks as you make them before committing to them.)
Let’s work with the following edits on girldevelopit.com:
- Change the headline to read: “Just Do It. Write Code”
- Hide the element that contains the map
- Delete the press logos section
- Place the top nav of “supporters” in its hover state
- Change the “flourish” logo in the headline to one of puppies
- Accessibility in Web development means enabling as many people as possible to use Web sites, even when those people’s abilities are limited in some way.
- The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.
- A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times.
WAI-ARIA is a shorthand for (Web Accessibility Initiative – Accessible Rich Internet Applications). WAI-ARIA is a specification written by the W3C, defining a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve accessibility wherever it is lacking. ARIA breaks down into 3 categories:
- Roles: define the purpose of an element
- Properties: help better describe what an element can do
- An element can only have one ARIA role at a time, but can have as many properties and states as necessary.
An important point about WAI-ARIA attributes is that they don’t affect anything about the web page, except for the information exposed by the browser’s accessibility APIs (where screenreaders get their information from). WAI-ARIA doesn’t affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.
Rules of ARIA Use
There are a few core rules to keep in mind when using ARIA:
- If you can use native HTML elements and attributes to communicate the proper semantics (like
<button>, etc.) and behavior then do so. Adding ARIA support where it’s not needed is redundant code that isn’t doing anything. For the most part it won’t lead to problems, but it is a waste of time.
- Don’t change native semantics, unless you really have to.
- All interactive controls such as a button, sliding control, or drag-and-drop widget must be usable by the keyboard.
- There are 2 ways to hide information from the accessibility tree, which should be used very sparingly for situations where content is unimportant or meant to be hidden. An example of this would be hiding icons that have been added to display extra decoration or branding. You can do this either with
aria-hidden=”true”. You should never use these on an element that is visible and can be focused with the keyboard, such as an input field or a link.
- Lastly, all interactive elements such as form fields should have a name associated with them. Something like a
<label>is perfect, and with ARIA, you can even specify that a certain element is labelled by or described by another element.
- Elements such as
<aside>when read aloud help clarify what part of the html page someone is focused on.
- These elements have default implicit ARIA roles.
- Keep an eye on these so you can avoid writing redundant code.
More Obscure Semantic HTML5 Elements
<q></q>: inline quoted text
<time></time>: date or specific time
<cite></cite>: reference to a cited book, play, etc
<input type="email"></input>: specific type of input field
<figcaption></figcaption>: detailed caption on an image
<code></code>: code snippet
<aside></aside>: chunk of text that isn’t the primary focus of the page
<article></article>: small subsection of content
Example: <nav></nav> tags have an implicit role="navigation".
Alt Attributes for Yo Images!
- Hugely important
- Low hanging fruit, easy to use on images.
- Be verbose.
- Just do it.
bad: <img src="mountain.jpg" alt="mountain" /> good: <img src="mountain.jpg" alt="The cascade mountains at sunset in January" />
Title Attributes for Yo Links!
- Low hanging fruit on anchor tags.
- Not necessary for all links, but make sure to use them for your icon anchors – you know, things like your facebook, twitter, etc icons:
<a class="facebook-icon" title="Facebook"><a/>
Lang attribute on Yo HTML!
- Low hanging fruit for HTML
- As far as non-english speaking screen readers are concerned, when they land on an english-speaking web page without lang attribute, it will be spoken with the screen reader language - making it impossible to understand - unless the screen reader user disables language switching in the screen reader.
- Just do it
<html lang="en"> </html>
ARIA Landmark Roles
One of the easiest ARIA features to implement, and one that provides significant immediate benefits to screen reader users, is landmark roles. To add them, simply add a relevant role attribute to an appropriate container within your HTML. This allows the screen reader to quickly jump to that section of the page. Below, you will find an example of how you might utilize the different landmark roles for your layout:
- The banner, main, and contentinfo roles are meant to be used only one time per page
- Take care in using
role="application"- When assistive technologies encounter content that’s marked up with
role=”application”they stop listening for users’ keystrokes and hand off all functionality to the application. This is due to an expectation that the application has its own model for navigating and operating all controls by keyboard. It generally should not be used.
Below you will find a code example of defining three landmark roles:
<header role="banner"> </header> <main role="main"> </main> <footer role="contentinfo"> </footer>
Label and Describe Elements
aria-label: property that defines a short title for an element
aria-labelledby: references the ID of another element, which is a short title for the element
aria-describedby: is just like aria-labelledby – but is meant for longer descriptions instead of short titles. This is read after the field-type is stated
<input type="text" aria-label="First name" placeholder="Grace">
<button aria-describedby="revertTooltip">Revert</button> <div role="tooltip" id="revertTooltip">Reverting will undo any changes that have been made since the last save.</div>
Now it’s important to remember that we don’t need to label everything, especially if there’s already a predefined way of labelling an element such as a
title attribute, or an image’s
alt attribute. We only need to label something if the HTML doesn’t clearly indicate the purpose of an important element.
There are a lot of various ARIA roles and attributes that can be applied to forms, but we’re just going to highlight some of the more important ones to include:
form: simple and an implicit role for
search: role for a form with the primary function of searching data
aria-required: property indicating whether a field is required
aria-invalid: property indicating that the value of an input field is invalid (wait until after form submission to add this)
Important to remember:
- Each form field should have a valid
<label>that is referenced with the
forattribute. If this isn’t possible, then you can use the ARIA labelling methods discussed above. You cannot substitute the placeholder attribute for a label because it’s not meant to be handled as a label; a placeholder is meant to simply be an example of what you’re supposed to enter in that field.
<p id="formLabel">Information Form</p> <form role="form" aria-labelledby="formLabel"> <label for="name">Name</label> <input id="name" type="text" placeholder="John Doe" value=""> <label for="email">Email*</label> <input id="email" type="email" placeholder="email@example.com" value="" aria-required="true"> <span id="genderLabel">Gender</span> <div role="radiogroup" aria-labelledby="genderLabel"> <input type="radio" role="radio" name="gender" id="male" value="Male"> <label for='male'>Male</label> <br> <input type="radio" role="radio" name="gender" id="female" value="Female"> <label for='female'>Female</label> <br> <input type="radio" role="radio" name="gender" id="other" value="Other"> <label for='other'>Other</label> </div> <label for="comment">Comment*</label> <textarea id="comment" aria-multiline="true" aria-required="true"></textarea> <input type="submit" value="Submit"> </form>
Take the following HTML snippet and make it accessible using explicit semantic HTML, ARIA roles, and attributes.
<div> <p>Main Title</p> <form action="/" method="get"> <input type="search"> <input type="submit"> </form> </div> <ul> <li><a href="/">Home</a></li> <li><a href="/products">About</a></li> <li><a href="/about">Contact</a></li> </ul> <div> <div> <p>Content Title Subject One</p> <p>This is the content of this important section</p> </div> <div> <p>Content Title Subject Two</p> <p>This is the content of the section important section</p> </div> <div> <img src="mountain.jpg"> </div> </div> <div> <span>Copyright &copy; Aurelio De Rosa 2014</span> </div>
Perfect is the enemy of good
For many people, the fear of not getting EVERYTHING right when it comes to accessibility causes them to not do accessibility at all. Don’t be that person.
Helping one group of people is a good place to start. There's a temptation with accessibility to think it has to be perfect. This is technology. This is people. We don't do perfect. It never happens. So, really, please don't go out there and think that if you're going to do accessibility that you have to get everything right. Perfect is, very much, the enemy of good. - Leonie Watson, Accessibility Engineer