ptg HTML5 also drops a number of tags that were deprecated in previous HTML specifica- tions. I’ve noted which tags have been dropped throughout the book. It’s unknown whether browsers will ignore those tags if a page uses the HTML5 DOCTYPE, but they are no longer part of HTML5. One important new feature of HTML5, which I discussed in Lesson 12, “Integrating Multimedia: Sound, Video, and More,” is native video playback without plug-ins. The <video> tag can be used to embed movies in web pages without the Flash player or any other video player. Likewise, HTML5 also enables you to create images using markup via the <canvas> element. The <canvas> tag is used to define the size and location of the generated image, and the actual image is defined using JavaScript. The <canvas> element will allow web programmers to do things such as create graphs on-the-fly without using external images. Browsers like Safari, Google, Chrome, and Firefox already support the <canvas> element. In addition to new tags, HTML5 provides some new interfaces for JavaScript program- mers. For programmers, HTML5 enables web applications to behave a lot more like desktop applications, incorporating features that have been implemented outside the browser by Flash and other plug-ins, and making some features that developers imple- ment in JavaScript more powerful. HTML5 supports local storage for web applications, enabling websites to actually store data on the user’s computer. This enables applications to manage their own data cache on each computer. They can store images or other web content locally so that it doesn’t have to be downloaded each time the user visits the site, or store application the user enters on their own computer. For example, using local storage, you could create a browser-based email client that allows users to draft outgoing emails when the computer is offline, and then send them all when the user visits the application after reconnecting to the Internet. HTML5 includes drag-and-drop features that can be used to build richer applications. You can already add drag and drop to applications using JavaScript, but it only applies to elements on a single web page. In current browsers, you can create a catalog that enables users to drag items to a shopping cart. With HTML5 drag and drop, you can enable users to drag items from one web page to another, or even drag things from other applications to the browser. For example, you could create a page that enables users to upload files simply by dragging them from the desktop into the browser window, rather than using the form control for files. The new drag-and-drop features have already been imple- mented in Firefox. 576 LESSON 19: Designing for the Real World Download from www.wowebook.com ptg What’s Not in HTML5 As mentioned, HTML5 removes a number of tags that have been slated for removal for some time. In most cases, the tags and attributes that were removed are either redundant or have been replaced by CSS properties. For example, the <acronym> tag has been removed because it serves the same purpose as the <abbr> (abbreviation) tag. The bor- der attribute of the <img> tag has been removed because you can use the CSS border property to achieve the same effect. However, some tags and attribute have been removed without equivalent replacements. The biggest feature removed by HTML5 is frames. HTML5 supports the <iframe> tag, which can be styled using CSS, but <frameset>, <frame>, and <noframes> have all been removed. In the future, if you want to create a framed site in the traditional sense, you’ll need to use the HTML 4.01 Frameset or XHTML 1.0 Frameset DOCTYPEs. Using HTML5 A lot of web designers are eager to dive in and start using all the new features in HTML5. They require fewer browser add-ons, provide new functionality, and enable designers to create simpler, more readable markup. The problem is that not even the most recent browsers offer full support for HTML5, and older browsers don’t support it at all. Therefore, if you want a feature to be available to your full audience, even if you use HTML5, you have to provide an alternate accommodation that works for other users. That said, it’s probably time to start migrating to the HTML5 future. This begins with the HTML5 DOCTYPE, which I’ve used throughout the book for pages that consist of valid HTML5. It is <!DOCTYPE html> Here’s the DOCTYPE for HTML 4.01: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”> As you can see, one of the charms of the HTML5 DOCTYPE is that it’s short. It may be the first DOCTYPE declaration that’s easy to type in from memory. All current browsers recognize the HTML5 DOCTYPE and render pages that use it in their standards-compliant mode, rather than quirks modes that mimic older, incorrect implementations of standards in old browsers. The only catch is that if you’re going to use the HTML5 DOCTYPE, be sure to avoid using any tags or attributes that have been removed from HTML5. Migrating to HTML5 577 19 Download from www.wowebook.com ptg This is the other big step you should take toward HTML5. New web pages should use CSS to modify the appearance of web pages rather than HTML. Sticking with only those tags and attributes in HTML5 and using CSS for everything else is a big step along that path. HTML5 and XML One of the biggest changes from XHTML 1.0 to HTML5 is that unlike XHTML 1.0, HTML5 does not require documents to be valid XML. In XHTML 1.0, every tag had to be closed, and every attribute was required to have a value to be valid XML documents. HTML5 is like HTML 4.01—closing tags and attribute values are not strictly required. That said, HTML5 documents can be formatted using valid XML—that’s the approach I’ve taken in this book. Either approach is acceptable and browsers support both. To indicate to the browser whether the page is valid XML, the Content-type header is used. When a browser requests a web page, or an image, or any other resource from a server, the response from the server includes a number of headers. These headers are used by the server and browser to exchange information that isn’t part of the web page. The Content-type header is what the server uses to tell the browser what kind of resource it’s sending. The content types themselves come in two parts, separated by a slash. The part before the slash describes the general type of the file, and the part after the slash identifies the specific format of the file. So when a JPEG image is sent to the browser, the content type is image/jpeg. Regular web pages use the content type text/html. The content type enables the browser to figure out what to do with the resource. Most of the time, it displays it in the browser, but if the content type is appli- cation/pdf, it knows it needs to open a PDF reader and use it to display the file. The HTML5 specification distinguishes between HTML5 that is valid XML and HTML5 that isn’t using content types. The content type for vanilla HTML is text/html. If you want the browser to treat the document as valid XML, you can use application/xml or application/xhtml+xml. Right now, however, Microsoft Internet Explorer does not sup- port those content types, so you should serve your HTML5 documents as text/html, whether they’re valid XML. Ultimately, it’s up to you whether you choose to write XML-compliant HTML. Many web designers are accustomed to XHTML 1.0 and write valid XML, and many tools do a better job of catching errors in valid XML. On the other hand, if you’re starting from scratch, you can do what you like. 578 LESSON 19: Designing for the Real World Download from www.wowebook.com ptg XHTML 1.0 and HTML 4.01 Most web pages that exist today were created to conform to the XHTML 1.0 or HTML 4.01 specifications. Many of them are not actually valid but work fine in the popular browsers. So if you’re working on an existing website, chances are you’ll be working with pages in one of these two formats. XHTML defines HTML so that it conforms to the XML specification. When you want to know whether a particular tag or attribute is valid, check out the HTML specification. When you want to know how to close a tag that has no closing tag, such as <br>, consult with the XHTML spec. In earlier lessons, you learned about the various flavors of HTML 4.01 and XHTML 1.0 and how each of them is geared toward users of older or newer browsers: n HTML 4.01 or XHTML 1.0 Transitional—For those who want to provide sup- port for older browsers n HTML 4.01 or XHTML 1.0 Frameset—For sites that want to use frames in a standards-compliant manner n HTML 4.01 or XHTML 1.0 Strict—For those who want to develop pages that strictly adhere to the HTML 4.0 or XHTML 1.0 specification by not using depre- cated elements or attributes You may encounter these three DOCTYPEs when you work on existing pages, or if you want to create a site that uses frames, you’ll need to use one of the two frameset DOCTYPEs. What Is Accessibility? Accessibility is basically the effort to make websites as usable as possible for people with disabilities. This involves the creation of software and hardware that enables people with various disabilities to use computers and the Web. It also means addressing accessibility concerns in the design of HTML as a markup language and efforts on the part of web designers to incorporate accessibility into their websites. When a person with impaired vision uses a screen reader to visit a website, there are things the site’s author can do to make that experience as rich and fulfilling as possible given the user’s disability. Common Myths Regarding Accessibility Historically, there has been some resistance among web designers toward building web- sites in an accessible manner. This resistance has arisen not due to a want to discriminate against people who might benefit from accessible design, but rather from a fear that What Is Accessibility? 579 19 Download from www.wowebook.com ptg accessibility will limit designers’ options in how they create their sites. Also accessibility seems like it will add additional work, and most people have too much to do already. For a long time, many people thought that accessible was a code word for all text. It was believed that adding accessibility meant putting all your content in a single column run- ning straight down the page and avoiding the bells and whistles that many people believe are necessary for an attractive website. This couldn’t be further from the truth. Although some common techniques can interfere with accessibility, that doesn’t mean that you must remove any images, sounds, or multimedia from your website. Nor does it dictate that your layout be simplified. The demand that accessibility places on designers is that they write clean, standards- compliant markup, take advantage of HTML features that improve accessibility, and use tags as they are intended to be used in the specification rather than based on how they make your pages look in the browser. The best example here is tables. At one time, nearly all websites used tables not only for showing things like tables of statistics, but also for controlling the layout of entire pages. These types of approaches run counter to how HTML was intended to be used and make things much more difficult for users with alternative browsers. To continue to use complex layouts in an accessible world, you have to upgrade to cur- rent techniques—in other words, create your layouts using CSS. Just as this approach provides a cutting-edge look and feel in the latest browsers and yet gracefully degrades to still display information adequately in older browsers, it provides the same benefits in alternative browsers. Because the markup is so simple and is properly used when you use CSS to handle layout, alternative browsers for the disabled can handle the markup just fine. That’s not the case when you use eight levels of nested tables to make your page look the way you want it to. The other common misapprehension for accessibility is that it will require a lot of extra work on your part. It does require some extra work—creating your pages so that they take advantage of accessibility features in HTML is more work than leaving them out. However, in many cases, coding for accessibility will help all your users, not just those using alternative browsers. Section 508 Section 508 is a government regulation specifying that U.S. federal government agencies must provide access for all users, including those with disabilities, to electronic and 580 LESSON 19: Designing for the Real World Download from www.wowebook.com ptg information technology resources. It requires that federal agencies consider the needs of disabled users when they spend money on computer equipment or other computer resources. What this boils down to is that federal websites must be designed in an acces- sible fashion. Not only did Section 508 change the rules of the game for many web designers (anyone involved with federal websites), but it also raised the profile of accessibility in general. Thanks in part that people didn’t understand the implications of Section 508 at first, peo- ple started thinking a lot about accessibility and what it meant for the Web. Alternative Browsers 581 19 For more information on Section 508, see http://www.section 508.gov/. Alternative Browsers Just as there are a number of disabilities that can make it more challenging for people to use the Web, there are a number of browsers and assistive technologies that are designed to level the playing field to a certain degree. I discuss some common types of assistive technologies here so that when you design your web pages you can consider how they’ll be used by people with disabilities. Disabled users access the Web in a variety of ways, depending on their degree and type of disability. For example, some users just need to use extra large fonts on their com- puter, whereas others require a completely different interface from the standard used by most people. Let’s look at some of the kinds of browsers specifically designed for disabled users. For users who read Braille, a number of browsers provide Braille output. Screen readers are also common. Instead of displaying the page on the screen (or in addition to displaying it), screen readers attempt to organize the contents of a page in a linear fashion and use a voice synthesizer to speak the page’s contents. Some browsers also accept audio input— users who are uncomfortable using a mouse and keyboard can use speech recognition to navigate the Web. Another common type of assistive technology is a screen magnifier. Screen magnifiers enlarge the section of the screen where the user is working to make it easier for users with vision problems to use the computer. NOTE Download from www.wowebook.com ptg Writing Accessible HTML When it comes to writing accessible HTML, there are two steps to follow. The first step is to use the same tags you normally use as they were intended. The second step is to take advantage of HTML features specifically designed to improve accessibility. I’ve already mentioned a number of times that tags should be used based on their semantic meaning rather than how they’re rendered in browsers. For example, if you want to print some bold text in a standard size font, <h4> will work, except that it not only boldfaces the text, it also indicates that it’s a level 4 heading. In screen readers or other alternative browsers, that might cause confusion for your users. Tables This problem is particularly acute when it comes to tables. I’ve already mentioned that it’s not a good idea to use tables for page layout when you’re designing for accessibility. Alternative browsers must generally indicate to users that a table has been encountered, and then unwind the tables so that the information can be presented to the user in a linear fashion. To make things easier on these users, you should use tables as intended where you can. Even if you can’t avoid using tables to lay out your page, be aware of how the table will be presented to users. If possible, try to avoid putting lots of navigation text and other supplemental text between the beginning of the page and the content the user is actually looking for. When you’re presenting real tabular data, it’s worthwhile to use all the supplemental tags for tables that are all too often ignored. When you’re inserting row and column headings, use the <th> tag. If the default alignment or text presentation is not to your liking, use CSS to modify it. Some browsers will indicate to users that the table headings are dis- tinct from the table data. Furthermore, if you label your table, using the <caption> tag is a better choice than just inserting a paragraph of text before or after the table. Some browsers indicate that the text is a table caption. Finally, using the summary attribute of the <table> tag can be a great aid to users with alternative browsers. How you use the summary and caption are up to you. The caption can explain what the table contains, and the summary can explain how the data in the table is used if it’s not obvious from the row/column headings. Here’s an example of a table that’s designed for accessibility: <table summary=“This is the famous Boston Consulting Group Product Portfolio Matrix. It’s a two by two matrix with labels.” border=“1” cellpadding=“12”> <caption>Boston Consulting Group Product Portfolio Matrix</caption> <tr> <td colspan=“2” rowspan=“2”><br /></td> 582 LESSON 19: Designing for the Real World Download from www.wowebook.com ptg <th colspan=“2”>Market Share</th> </tr> <tr> <th>High</th> <th>Low</th> </tr> <tr> <th rowspan=“2”>Market Growth</th> <th>High</th> <td align=“center”>Star</td> <td align=“center”>Problem Child</td> </tr> <tr> <th>Low</th> <td align=“center”>Cash Cow</td> <td align=“center”>Dog</td> </tr> </table> Links As mentioned in Lesson 18, “Writing Good Web Pages: Do’s and Don’ts,” avoiding the “here” syndrome is imperative, particularly when it comes to accessibility. Having all the links on your page described as “click here” or “here” isn’t helpful to disabled users (or any others). Just thinking carefully about the text you place inside a link to make it descriptive of the link destination is a good start. To make your links even more usable, you can use the title attribute. The title attribute is used to associate some descriptive text with a link. It is used not only by alternative browsers, but many standard browsers will display a tool tip with the link title when the user holds her mouse pointer over it. Here are some examples: <a href=“http://www.dmoz.org/” title=“The volunteer maintained directory.”>dmoz</a> <a href=“document.pdf” title=“1.5 meg PDF document”>Special Report</a> Navigational links are a special case because they usually come in sizable groups. Many pages have a nice navigation bar right across the top that’s useful to regular users who can skim the page and go directly to the content that they want. Users who use screen readers with their browsers and other assistive technologies aren’t so lucky. You can imagine what it would be like to visit a site that has 10 navigational links across the top of the page if you relied on every page being read to you. Every time you move from one page to the next, the navigation links would have to be read over again. Writing Accessible HTML 583 19 Download from www.wowebook.com ptg There are a few ways around this that vary in elegance. If you’re using CSS to position elements on your page, it can make sense to place the navigational elements after your main content in your HTML file, but use CSS to position them wherever you like. When a user with a screen reader visits the site, he’ll get the content before getting the navigation. You can then include a link that skips to the navigation at the top of the page, and hide it using CSS. Users with screen readers can jump to the navigation if they need to but won’t be required to listen to it on every page. 584 LESSON 19: Designing for the Real World It’s worth remembering that many disabled users rely on key- boards to access the Web. You can make things easier on them by using the accesskey and tabindex attributes of the <a> tag to enable them to step through the links on your page in a logical order. This proves particularly useful if you also include forms on your page. For example, if you have a form that has links inter- spersed in the form, setting up the tabindex order so that the user can tab through the form completely before he runs into any links can save him a lot of aggravation. This is the sort of conve- nience that all of your users will appreciate, too. Images Images are a sticky point when it comes to accessibility. Users with impaired vision might not appreciate your images. However, clever design and usage of the tools pro- vided by HTML can, to a certain degree, minimize the problem of image usage. Images are known for having probably the best-known accessibility feature of any HTML element. The alt attribute has been around as long as the <img> tag and provides text that can stand in for an image if the user has a text-only browser or the image weren't downloaded for some reason. Back when everybody used slow dialup connec- tions to the Internet, it was easy to become intimately familiar with alt text because it displayed while the images on a page downloaded. Later, some browsers started showing alt text as a tool tip when the user let her mouse pointer hover over an image. Despite that alt text is useful, easy to add, and required by the HTML5 specification, many pages on the Internet still lack meaningful alternative text for most (if not all) of their images. Taking a few extra minutes to enter alt text for your images is a must for anyone who uses HTML that includes images. Also bear in mind that using alt=““ is TIP Download from www.wowebook.com ptg perfectly valid and is sometimes appropriate. In particular, some sites use small images to help position elements on a page. Although this practice is strongly discouraged, it’s still used. Text-based browsers will, in the absence of alt text, generally display some- thing like [IMAGE] on the page. If you include the alt attribute but leave it empty, the label IMAGE will be left out, making things easier on your users. HTML also provides another way of describing images that’s meant to improve accessi- bility: the longdesc attribute of the <img> tag. The longdesc attribute is intended to be used as a place to enter long descriptions of images. For example, if an image is a chart or graph, you can explain how it is used and what information it is intended to convey. If the picture is a nice photo of a waterfall, you can describe the waterfall. In many cases, images are used simply to make web pages flashier or aesthetically pleasing, and nothing more than alt text is required. However, when the actual meaning of a page is conveyed through the use of images, providing descriptions of those images is a key to accessibil- ity. For example, suppose that you’re working for a financial publication, and a story on the declining stock market includes a graph showing the consistent decline of the major indexes over the past few years. In print, that image would probably include a caption explaining what’s in the image. On the Web, you could put that caption in the image’s longdesc attribute. Or if you prefer, you could put it on the page as a caption, as long as your layout indicates in some way that the caption refers to the image in question. Here’s an example of what I’m talking about: <img src=“graph1.gif” longdesc=“Graph showing that the S&P 500 and Dow Jones Industrial Average have dropped an average of 20% annually over the last 3 years.” /> Writing Accessible HTML 585 19 The longdesc attribute has been removed from HTML5. The spec- ification instead recommends that the page include a link to a long description for an image if appropriate. There’s one final area to discuss when it comes to images: the marriage of images and links in the form of image maps. As you might imagine, image maps can be an accessi- bility issue. Some browsers will display the links from an image map as a menu, but the only certain way around this is to provide users with an alternative to image maps in the form of text links. Whenever you use an image map, make sure to include text equiva- lents of the links somewhere on the page. NOTE Download from www.wowebook.com . step along that path. HTML5 and XML One of the biggest changes from XHTML 1. 0 to HTML5 is that unlike XHTML 1. 0, HTML5 does not require documents to be valid XML. In XHTML 1. 0, every tag had to be. who want to provide sup- port for older browsers n HTML 4. 01 or XHTML 1. 0 Frameset—For sites that want to use frames in a standards-compliant manner n HTML 4. 01 or XHTML 1. 0 Strict—For those who. the HTML5 future. This begins with the HTML5 DOCTYPE, which I’ve used throughout the book for pages that consist of valid HTML5 . It is <!DOCTYPE html& gt; Here’s the DOCTYPE for HTML 4. 01: <!DOCTYPE