Creating an Accessible Updatable Region

We do a lot of things with Ajax In our web applications these days. Standard practice Is to fire off some sort of visual effect to give the user a clue that something has changed on the page. However, a person using a screen reader obviously isn’t going to be able to see any visual cues. The WLA-ARLA specification provides a pretty nice alternative solution that currently works in IE, Firefox, and Safari with various popular screen readers.

The AwesomeCo executive director of communications wants a new home page. It should have links to a “services” section, a “contact” section, and an “about” section. He insists that the home page shouldn’t scroll because “people hate scrolling.” He would like you to implement
a prototype for the page with a horizontal menu that changes the page’s main content when clicked. That’s easy enough to Implement, and with the aria-live attribute, we can do something we haven’t been able to do well before—implement this type of interface in a way that’s friendly to screen readers.

Let’s build a simple interface like Figure 5.1, on page 106. We’ll put all the content on the home page, and if JavaScript is available to us, we’ll hide all but the first entry. We’ll make the navigation links point to each section using page anchors, and we’ll use jQuery to change those anchor links into events that swap out the main content. People with JavaScript will see what our director wants, and people without will still be able to see all the content on the page.

Creating the Page

We’ll start by creating a basic HTML5 page, and we’ll add our Welcome section, which will be the default section displayed to users when they visit the page. Here’s the code for the page with the navigation bar and the jump links:

<!DOCTYPE html>
<html lang=”en-US”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<t i tle>Awe someCo</ti tl e>

<1 ink rel=”stylesheet” href=”style.css” type=”text/css”>
</head>
<body>
<header id=”header”>
<hl>AwesomeCo </hl>
<nav>
<ul>
<1 i x a href=”#wel come’VWel come</ax/l i>
<1 i x a href=”#services”>Servi ces</ax/l i>
<1 i x a href=”#contact”>Contact</ax/l i>
<1 i x a href=”#about”>About</ax/l i>
</ul>
</nav>
</header>
<section id=”content”
role=”document” aria-1ive=”assertive” aria-atomic=”true”>
<section id=”welcome”>
<header>
<h2>Welcome</h2>
</header>
<p>The welcome section</p>
</section>
</section>
<footer id=”footer”>
<p>&copy; 2010 AwesomeCo.</p>
<nav>
<ul>
<1 i x a href=”http://awesomeco.com/”>Home</ax/l i>
<1 i x a href=”about”>About</ax/l i>
< l i x a href=”terms.html”>Terms of Servi ce</ax/l i>
<1 i x a href=”privacy.html “>Pri vacy</ax/l i>
</ul>
</nav>
</footer>
</body>
</html>

The Welcome section has an ID of welcome, which matches the anchor in the navigation bar. We can declare our additional page sections in the same fashion.

<section id=”services”>
<header>
<h2>Servi ces</h2>
</header>
<p>The services section</p>
</section>

A mock-up of the home page

<section id=”contact”>
<header>
<h2>Contact</h2>
</header>
<p>The contact section</p>
</section>
<section id=”about”>
<header>
<h2>About</h2>
</header>
<p>The about section</p>
</section>

Our four content regions are wrapped by this markup:

<section id=”content”
role=”document” aria-1ive=”assertive” aria-atomic=”true”>

The attributes on this line tell screen readers that this region of the page updates.

Polite and Assertive Updating

There are two types of methods for alerting the user to changes on the page when using aria-live. The polite method is designed to not interrupt the user’s workflow. For example, if the user’s screen reader is reading a sentence and another region of the page updates and the mode is set to polite, then the screen reader will finish reading the current sentence. However, if the mode was set to assertive, then it’s considered high priority, and the screen reader will stop and begin reading the new content. It’s really important that you use the appropriate type of interruption when you’re developing your site. Overuse of “assertive” can disorient and confuse your users. Only use assertive if you absolutely must. In our case, it’s the right choice, because we will be hiding the other content.

Atomic Updating

The second parameter, aria-atomic=true, instructs the screen reader to read the entire contents of the changed region. If we set it to false, it would tell the screen reader to only read nodes that changed. We’re replacing the entire content, so telling the screen reader to read it all makes sense in this case. If we were replacing a single list item or appending to a table with Ajax, we would want to use false instead.

Hiding Regions

To hide the regions, we need to write a little bit of JavaScript and attach it to our page. We’ll create a file called application.js, and then we include this file as well as the jQuery library on our page.

<script type=”text/javascript”
charset= “utf-8″
src=”http://ajax.googleapis.com/ajax/1ibs/jquery/1.4.2/jquery.min.js”>
</script>
<script type=”text/javascript”
charset= “utf-8″
src=”javascripts/application.js”>
</script>

Our application.js file contains this simple script:

Une l // HTML5 structural element support for IE 6, 7, and 8
document.createElementC”header”);
document.createElementC”footer”);
document.createElement(“section”);
5 document.createElementC’aside”) ;
document.createElement(“artic7e”) ;
document.createElementC”nav”);

$ (function (){
$(“#services, #about, #contact”) .hide() .addCl ass (“hidden”) ;
$(“#welcome”).addClass(“visib7e”);
$(“nav ul”).click(function(event){
target = $(event.target);
if(target.is(“a”)){
event.preventDefault();
if ( $(target.attr( “href”)) .hasdass(“hidden”) ){
20 $(” .visible”) . removed ass ( “vi si ble”)
.addClass(“hidden”)
,hide() ;
$(target.attr(“href”))
.removed ass(“hidden”)
25 . addCl ass (“visible”)
. show() ;
};
};
so });
} ) ;

On line 11, we hide the “services,” “about,” and “contact” sections. We also apply a class of “hidden” to them, and then on the next line we apply a class of “visible” to the default  “welcome” section. Adding these classes makes it really easy to identify which sections need to be turned off and on when we do the toggle.

We capture any clicks to the navigation bar on line 14, and then we determine which element was clicked on 17. If the user clicked a link, we check to see whether the corresponding section is hidden. The href attribute of the clicked link can easily help us locate the corresponding section using jQuery selectors, which you can see on line 19.

If it’s hidden, we hide everything else and then show the selected section. That’s all there is to it. The screen readers should detect the region changes.

Falling Back

Like roles, this solution can be used right now by the latest versions of screen readers. By following good practices such as unobtrusive JavaScript, we have a simple implementation that can work for a reasonably wide audience. Older browsers and screen readers will ignore
the additional attributes, so there’s no danger in adding them to our markup.

The Future

HTML5 and the WIA-ARIA specification have paved the way for a much more accessible Web. With the ability to identify changing regions on the page, developers can develop richer JavaScript applications without worrying so much about accessibility issues.

In-Place Editing with contenteditable

We’re always looking for ways to make it easier for people to interact with our applications. Sometimes we want a user of our site to edit some information about themselves without having to navigate to a different form. We traditionally implement in-place editing by watching text regions for clicks and replacing those regions with text fields. These fields send the changed text back to the server via Ajax. HTML5’s contenteditable tag takes care of the data-entry part automatically. We’ll  still have to write some JavaScript to send the data back to the server
so we can save it, but we no longer have to create and toggle hidden forms.

One of AwesomeCo’s current projects lets users review their account profile. It displays their name, city, state, postal code, and email address. Let’s add some in-place editing to this profile page so that we end up with an interface like Figure 3.3, on the next page.

Before we get started, I want you to know that implementing a feature that relies on JavaScript without first implementing a server-side solution goes against everything I believe in when it comes to building accessible web applications. We’re doing it this way here because I want to focus on the features of the contenteditable attribute, and this is not production code. Always, and I mean always, build the solution that does not require JavaScript, then build the version that relies on scripting, and finally be sure to write automated tests for both paths so that you’re more likely to catch bugs if you change one version and not the other.

The Profile Form

HTML5 introduces the contenteditable attribute that is available on almost every element. Simply adding this attribute turns it into an editable field.

In-place editing<hl>User information</hl>
<div id=”status”x/div>
<ul>
<li>
<b>Name</b>
<span id=”name” contenteditable=”true”>Hugh Mann</span>
</l i>
<li>
<b>Ci ty</b>
<span id=”city” contenteditable=”true”>Anytown</span>
</l i>
<li>
<b>State</b>
<span id=”state” contenteditable=”true”>OH</span>
</l i>
<li>
<b>Postal Code</b>
<span id=”postal_code” contenteditable=”true”>92110</span>

</l i>

<li>
<b>Email</b>
<span id=”email” contenteditab1e=”true”>[email protected]</span>
</l i>
</u1>

We can style this up with some CSS too. We’ll use some CSS3 selectors to identify the editable fields so they change color when our users hover over or select them.

Line l ul{1ist-style:none;}
1i{clear:both;}
5 li>b, li>span{
display: block;
float: left;
width: lOOpx;
}
li>span{
width:500px;
margin-left: 20px;
}
1i>span[contenteditable=true]:hover{
background-color: #ffc;
}
20 1i>span[contenteditable=true]:focus{
background-color: #ffa;
border: lpx shaded #000;
}

That’s it for the front end. Users can modify the data on the page easily. Now we have to save it.

Persisting the Data

Although the users can change the data, their changes will be lost if they refresh the page or navigate away. We need a way to submit those changes to our back end, and we can do that easily with jQuery. If you’ve ever done any Ajax before, this won’t be anything new to you.

$(function(){
var status = $(“#status”);
$ C”span[contented!table=trueJ”).blur(function 0{
var field = $(this) .attr(“id”) ;
var value = $(this) .text() ;
$ .postC’http://localhost:4567/users/l” ,
field + “=” + value,
function(data){
status.text(data);
}
);
} ) ;
} ) ;

We’ll add an event listener to every span on the page that has the contenteditable attribute set to true. Then, all we have to do is submit the data to our server-side script.

Falling Back

We’ve done a bunch of things that won’t work for some of our audience. First, we’ve created a dependency on JavaScript to save the edited results back to the server, which is a Bad Thing. Next, we’re using the focus pseudoclass to highlight the fields when they receive focus, and
some versions of IE don’t support that. Let’s handle the functionality first, and then we’ll deal with the visual effects.

Creating an Edit Page

Rather than worrying too much about various situations that might prevent a user from using our technique, let’s just give them the option to go to a separate page with its own form. Sure, it’s more coding, but think about the possible scenarios:

• A user doesn’t have JavaScript turned on and is using Internet Explorer 7.
• A user doesn’t have an HTML5-compatible browser.
• A user is using the latest Firefox with HTML5 support but still disabled JavaScript simply because they don’t like JavaScript (it happens all the time…more than you’d think).

When it comes down to it, making a form that does a POST to the same action that handled the Ajax update makes the most sense. How you do this is up to you, but many frameworks let you detect the type of request by looking at the accept headers to determine whether the
request came from a regular POST or an XMLHttpRequest. That way, you keep the server-side code DRY.5 We will hide the link to this form if the browser supports contenteditable and JavaScript.

So, create a new page called edit.html, and code up a standard edit form that posts to the same update action that our Ajax version uses.

<!DOCTYPE html>
<html lang=”en-US”>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
<title>Edi ti ng Profi 1e</title>
<link href=”style.css” rel=”stylesheet” media=”screen”>
</head>
<body>
<form action=”/users/l” method=”post” accept-charset=”utf-8″>
<fieldset id=”your_information”>
<1egend>Your Information</legend>
<ol>
<li>
<label
<input
</li>
<li>
<label
<input
</li>
<li>
<label
<input
</li>
<li>
<label
<input
</li>
<li>
<label
<input
</li>
</ol>
</fieldset>
<pxinput type=”submit” value=”Save”x/p>
</form>
</body>
</html>

Then, add a link to this page on show.html.

<hl>User information</hl>
<section id=”edit_profile_link”>
< p x a href=”edit.html”>Edit Your Profi 1 e</ax/p>
</section>
<div id=”status”x/div>

With the link added, we just need to modify our script a bit. We want to hide the link to the edit page and enable the Ajax support only if we have support for editable content.

if (document. getElementById(“ech’t_prof”! 7e_7in/c”) . contentEdi tabl e != null){

With the detection in place, our script looks like this:

$(function(){
if (document. getElementById(“ech’t_prof”! 7e_7in/c”) . contentEdi tabl e != null){
$C’#edit_profile_link”) .hideO ;
var status = $(“#status”);
$(“span[contented!table=true]”).blur(function(){
var field = $(this) .attr(“id”) ;
var value = $(this) .text() ;
$ .postC’http://Iocalhost:4567/users/l” ,
field + “=” + value,
function(data){
status.text(data);
}
);

} ) ;

With that in place, our users have the ability to use a standard interface or a quicker “in-place” mode. Now that you know how to implement this interface, remember to implement the fallback solution first. Unlike the other fallback solutions, this particular one cripples functionality if not
implemented.

The Future

Right now, if you add a JavaScript-based date picker to your site, your users have to learn how it works. If you’ve ever shopped online for plane tickets and made hotel reservations, you’re already familiar with the different ways people implement custom form controls on sites. It’s akin to using an ATM—the interface is often different enough to slow you down.

Imagine, though, if each website used the HTML5 date field, and the browser had to create the interface. Each site a user visited would display the exact same date picker. Screen-reading software could even implement a standard mechanism to allow the blind to enter dates easily.
Now think about how useful placeholder text and autofocus can be for users once it’s everywhere. Placeholder text can help screen readers explain to users how form fields should work, and autofocus could help people navigate more easily without a mouse, which is handy for the blind but also for users with motor impairments who may not use the mouse.

The ability for developers to turn any element into an editable region makes it easy to do in-place editing, but it could potentially change how we build interfaces for content  management systems.

The modern Web is all about interactivity, and forms are an essential part of that interactivity. The enhancements provided by HTML5 give us a whole new set of tools we can use to help our users.

Redefining a Blog Using Semantic Markup

One place you’re sure to find lots of content in need of structured markup is a blog. You’re going to have headers, footers, multiple types of navigation (archives, blogrolls, and internal links), and, of course, articles or posts. Let’s use HTML5 markup to mock up the front page of
the blog for AwesomeCo, a company on the cutting edge of Awesomeness.

To get an idea of what we’re going to build, take a look at Figure 2.1, on the following page. It’s a fairly typical blog structure, with a main header with horizontal navigation below the header. In the main section, each article has a header and a footer. An article may also have a pull quote, or an aside. There’s a sidebar that contains additional navigation elements. Finally, the page has a footer for contact and copyright information. There’s nothing new about this structure, except that this time, instead of coding it up with lots of div tags, we’re going to use specific tags to describe these regions.

It All Starts with the Right Doctype

We want to use HTML5’s new elements, and that means we need to let browsers and validators know about the tags we’ll be using. Create a new page called index.html, and place this basic HTML5 template into that file.

Line l <!D O C T Y P E h t m l >
2 <html lang=”en-US”>
3 <head>
4 <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />
5 <title>AwesomeCo Blog</title>
6 </head>
8 <body>
9 </body>
10 </html>

blog structure using HTML5

Take a look at the doctype on line 1 of that example. This is all we
need for an HTML5 doctype. If you’re used to doing web pages, you’re
probably familiar with the long, hard-to-remember doctypes for XHTML
like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN””http://www.w3.org/TR/xhtm11/DTD/xhtmll-transitional.dtd”>

Now, take another look at the HTML5 doctype:

<!DOCTYPE HTML>

That’s much simpler and much easier to remember.

The finished layout

The point of a doctype is twofold. First, it’s to help validators determine
what validation rules it needs to use when validating the code. Second,
a doctype forces Internet Explorer versions 6, 7, and 8 to go into
“standards mode,” which is vitally important if you’re trying to build
pages that work across all browsers. The HTML5 doctype satisfies both
of these needs and is even recognized by Internet Explorer 6.

Headers

Headers, not to be confused with headings such as hi, h2, and h3, may
contain all sorts of content, from the company logo to the search box.
Our blog header will contain only the blog’s title for now.

Une l <header id=”page_header”>
2 <hl>AwesomeCo Blog!</hl>
3 </header>

You’re not restricted to having just one header on a page. Each individual
section or article can also have a header, so it can be helpful to
use the ID attribute like I did on 1 to uniquely identify your elements. A
unique ID makes it easy to style elements with CSS or locate elements
with JavaScript.

Semantic markup is all about describing your content. If you’ve
been developing web pages for a few years, you’ve probably
divided your pages Into various regions such as header, footer,
and sidebar so that you could more easily identify the regions of
the page when applying style sheets and other formatting.
Semantic markup makes It easy for machines and people alike
to understand the meaning and context of the content. The
new HTML5 markup tags such as section, header, and nav help
you do just that.

Footers

The footer element defines footer information for a document or an adjacent
section. You’ve seen footers before on websites. They usually contain
information like the copyright date and information on who owns
the site. The specification says we can have multiple footers in a document
too, so that means we could use the footers within our blog
articles too.

For now, let’s just define a simple footer for our page. Since we can
have more than one footer, we’ll give this one an ID just like we did with
the header. It’ll help us uniquely identify this particular footer when we
want to add styles to this element and its children.

<footer id=”page_footer”>
<p>&copy; 2010 AwesomeCo.</p>
</footer>

This footer simply contains a copyright date. However, like headers,
footers on pages often contain other elements, including navigational
elements.

Navigation

Navigation is vital to the success of a website. People simply aren’t going
to stick around if you make it too hard for them to find what they’re
looking for, so it makes sense for navigation to get its own HTML tag.

Let’s add a navigation section to our document’s header. We’ll add links
to the blog’s home page, the archives, a page that lists the contributors
to the blog, and a link to a contact page.

Une l <header id=”page_header”>
<hl>AwesomeCo Blog!</hl>
<nav>
<ul>
5 <lixa href=”/”>Latest Posts</ax/l i>
<1 i x a href=”archives”>Archi ves</ax/l i>
<1 i x a href=”contributors”>Contri butors</ax/l i>
< l i x a href=”contact”>Contact Us</ax/li>
</ul>
io </nav>
</header>

Like headers and footers, your page can have multiple navigation elements.
You often find navigation in your header and in your footer, so
now you can identify those explicitly. Our blog’s footer needs to have
links to the AwesomeCo home page, the company’s “about us” page,
and links to the company’s terms of service and privacy policies. We’ll
add these as another unordered list within the page’s footer element.

<footer id=”page_footer”>
<p>&copy; 2010 AwesomeCo.</p>
<nav>
<ul>
<1 i x a href=”http://awesomeco.com/”>Home</ax/l i>
<1 i x a href=”about”>About</ax/l i>
< l i x a href=”terms.html”>Terms of Servi ce</ax/l i>
<1 i x a href=”privacy.html “>Pri vacy</ax/l i>
</ul>
</nav>
</footer>

We will use CSS to change how both of these navigation bars look, so
don’t worry too much about the appearance yet. The point of these new
elements is to describe the content, not to describe how the content
looks.

Sections and Articles

Sections are the logical regions of a page, and the section element is
here to replace the abused div tag when it comes to describing logical
sections of a page.

<section id=”posts”>
</section>

Don’t get carried away with sections, though. Use them to logically
group your content! Here we’ve created a section that will hold all the
blog posts. However, each post shouldn’t be in its own section. We have
a more appropriate tag for that.

Articles

The article tag is the perfect element to describe the actual content
of a web page. With so many elements on a page, including headers,
footers, navigational elements, advertisements, widgets, blogrolls, and
social media bookmarks, it might be easy to forget that people come
to your site because they’re interested in the content you’re providing.
The article tag helps you describe that content.

Each of our articles will have a header, some content, and a footer. We
can define an entire article like this:

<article>
<header>
<h2>How Many Should We Put You Down For?</h2>
<p>Posted by Brian on
<time datetime=”2010-10-01T14:39″>0ctober 1st, 2010 at 2:39PM</time>
</p>
</header>
<p>
The first big rule in sales is that if the person leaves empty-handed,
they’re likely not going to come back. That’s why you have to be
somewhat aggressive when you’re working with a customer, but you have
to make sure you don’t overdo it and scare them away.
</p>
<p>
One way you can keep a conversation going is to avoid asking questions
that have yes or no answers. For example, if you’re selling a service
plan, don’t ever ask &quot;Are you interested in our 3 or 5 year
service plan?&quot; Instead, ask &quot;Are you interested in the 3
year service plan or the 5 year plan, which is a better value?&quot;
At first glance, they appear to be asking the same thing, and while
a customer can still opt out, it’s harder for them to opt out of
the second question because they have to say more than just
&quot;no.&quot;
</p>
<footer>
< p x a href=”comments”xi>2 5 Comments</ix/a> . . .</p>
</footer>
</article>

We can use header and footer elements inside of our articles, which
makes it much easier to describe those specific sections. We can also
divide our article into multiple sections using the section element.

Asides and Sidebars

Sometimes you have content that adds something extra to your main
content, such as pullout quotes, diagrams, additional thoughts, or related
links. You can use the new aside tag to identify these elements.

<aside>
<P>
&quot;Never give someone a chance to say no when
selling your product.&quot;
</p>
</aside>

We’ll place the callout quote in an aside element. We’ll nest this aside
within the article, keeping it close to its related content.

Our completed section, with the aside, looks like this:

<section id=”posts”>
orticle>
<header>
<h2>How Many Should We Put You Down For?</h2>
<p>Posted by Brian on
<time datetime=”2010-10-01T14:39″>0ctober 1st, 2010 at 2:39PM</time>
</p>
</header>
<aside>
<p>
&quot;Never give someone a chance to say no when
selling your product.&quot;
</p>
</aside>
<p>
The first big rule in sales is that if the person leaves empty-handed,
they’re likely not going to come back. That’s why you have to be
somewhat aggressive when you’re working with a customer, but you have
to make sure you don’t overdo it and scare them away.
</p>
<p>
One way you can keep a conversation going is to avoid asking questions
that have yes or no answers. For example, if you’re selling a service
plan, don’t ever ask &quot;Are you interested in our 3 or 5 year
service plan?&quot; Instead, ask &quot;Are you interested in the 3
year service plan or the 5 year plan, which is a better value?&quot;
At first glance, they appear to be asking the same thing, and while
a customer can still opt out, it’s harder for them to opt out of
the second question because they have to say more than just
&quot;no.&quot;
</p>
<footer>
< p x a href=”comments”xi>2 5 Comments</ix/a> . . .</p>
</footer>
</article>
</section>

Now we just have to add the sidebar section.

Asides Are Not Page Sidebars!

Our blog has a sidebar on the right side that contains links to the
archives for the blog. If you’re thinking that we could use the aside
tag to define the sidebar of our blog, you’d be wrong. You could do it
that way, but it goes against the spirit of the specification. The aside is designed to show content related to an article. It’s a good place to show
related links, a glossary, or a pull out quote.

To mark up our sidebar that contains our list of prior archives, we’ll
just use another section tag and a nav tag.

<section id=”sidebar”>
<nav>
<h3>Archives</h3>
<ul>
<1 i x a href=”2010/10″>0ctober 2010</ax/l i>
<1 i x a href=”2010/09″>September 2010</ax/li>
<1 i x a href=”2010/08″>August 2010</ax/li>
<1 i x a href=”2010/07″>July 2010</ax/li>
<1 i x a href=”2010/06″>June 2010</ax/li>
<1 i x a href=”2010/05″>May 2010</ax/li>
<1 i x a href=”2010/04″>Apri 1 2010</ax/li>
<1 i x a href=”2010/03″>March 2010</ax/li>
<1 i x a href=”2010/02″>February 2010</ax/li>
<1 i x a href=”2010/01″>January 2010</ax/li>
</ul>
</nav>
</section>

That’s it for our blog’s structure. Now we can start applying styles to
these new elements.

Styling

We can apply styles to these new elements just like we’d style div tags.
First, we create a new style sheet file called style.ess and attach it to our
HTML document by placing a style sheet link in the header, like this:

<link rel=”stylesheet” href=”style.ess” type=”text/css”>

Let’s first center the page’s content and set some basic font styles.

body{
width:960px;
margin:15px auto;
font-family: Arial, “MS Trebuchet”, sans-serif;
p{
margin:0 0 20px 0;

P, 1 U
line-height:20px;
}

Next, we define the header’s width.

header#page_header{
width:100%;}

We style the navigation links by transforming the bulleted lists into
horizontal navigation bars.

header#page_header nav ul, #page_footer nav ul{
list-style: none;
margin: 0;
padding: 0;
}
#page_header nav ul li, footer#page_footer nav ul li{
padding:0;
margin: 0 20px 0 0;
display ¡inline;
}

The posts section needs to be floated left and given a width, and we also
need to float the callout inside the article. While we’re doing that, let’s
bump up the font size for the callout.

section#posts{
float: left;
width: 74%;
section#posts aside{
float: right;
width: 35%;
margin-left: 5%;
font-size: 20px;
line-height: 40px;
}

We’ll also need to float the sidebar and define its width.

section#sidebar{
float: left;
width: 2 5%;

If you need to implement a pledge meter or an upload
progress bar in a web application, you should investigate the
meter and progress elements introduced in HTML5.
The meter element lets us semantically describe an actual fixed
point on a meter with a minimum and maximum value. For your
meter to be in harmony with the specification, you shouldn’t
use your meter for things with arbitrary minimum or maximum
values like height and weight, unless you are talking about
something specific where you have set a specific boundary.
For example, if we have a fundraising website and we want to
show how close we are to our goal of $5,000, we can describe
that easily:

<section id=”pledge”>
<header>
<h3>0ur Fundraising Goal</h3>
</header>
<meter ti tl e= “L/SD” id=”pledge_goal ”
value= “2500” min=”0″ max= “5000”>
$2500.00
</meter>
<p>Help us reach our goal of $5000!</p>
</section>

The progress element is very similar to a meter, but it’s designed
to show active progress like you’d see if you were uploading a
file. A meter, by comparison, is designed to show a measurement
that’s not currently moving, like a snapshot of available
storage space on the server for a given user. The markup for a
progress bar is very similar to the meter element.

<progress id=”progressbar” max=100xspan>0</span>%</progress>

The meter and progress elements aren’t styled by any browsers
yet, but you can use JavaScript to grab the values in the meter
and build your own visualization, using the meter or progress to
semantically describe the data. You can see an example of
how you might do that by looking at the book’s example files
for the meter element.

And we need to define the footer. We’ll clear the floats on the footer so
that it sits at the bottom of the page.

footer#page_footer{
clear: both;
width: 100%;
display: block;
text-align: center;
}

These are just basic styles. From here, I’m confident you can make this
look much, much better.

Falling Back

Although this all works great in Firefox, Chrome, and Safari, the people
in management aren’t going to be too happy when they see the mess
that Internet Explorer makes out of our page. The content displays fine,
but since IE doesn’t understand these elements, it can’t apply styles to
them, and the whole page resembles something from the mid-1990s.
The only way to make IE style these elements is to use JavaScript to
define the elements as part of the document. That turns out to be really
easy. We’ll add this code to our head section of the page so it executes
before the browser renders any elements. We’ll place it inside a conditional
comment, a special type of comment that only Internet Explorer
will read.

<! — [i f It IE 9]>
<script type=”text/javascript”>
document.createElementC”nav”);
document.createElementC”header”);
document.createElementC”footer”);
document.createElementC”section”) ;
document.createElementC”aside”);
document.createElementC”article”) ;
</scri pt>
<![endif]–>

This particular comment targets any version of Internet Explorer older
than version 9.0. If we reload our page, it looks correct now.
We are creating a dependency on JavaScript, though, so you need to
take that into consideration. The improved organization and readability of the document make it worth it, and since there are no accessibility
concerns, because the contents still display and are read by a screen
reader, you’re only making the presentation seem grossly out-of-date to
your users who have disabled JavaScript intentionally.
This approach is fine for adding support for a handful of elements or for
understanding how you can add support. Remy Sharp’s brilliant HTMLShiv3
takes this approach much further and might be more appropriate
for incorporating fallback support if you’re looking to support many
more elements.