![Theory and Practice ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (16)
Destacado
Similar a Html5 accessibility
Similar a Html5 accessibility (20)
Último
Último (20)
Html5 accessibility
- 1. HTML5 and Accessibility John Slatin AccessU 2011 Virginia DeBolt, presenter www.webteacher.ws
- 20. A high level look
- 34. Section
- 45. The Aside as Sidebar
Notas del editor
- Web Hypertext Application Technology Working Group or WHATWG Lead by Ian Hickson
- W3C working group also lead by Ian Hickson
- HTML5 must go through two complete implementations before becoming a "proposed recommendation." That's projected to happen in 2022, But browsers have already started supporting many features HTML5. And browser implementation is what really counts in terms of what web designers can do now. So far, new HTML5 features don't make the web more accessible. Some features like longdesc have been dropped and the use of alt text has been muddied and confused. Headings are now an accessibility issue.
- From the start, the WHATWG worked under several principles The web app APIs are the most experimental part of HTML5. I'm not going to talk about them beyond saying that any web app you make may break at any time because the specs are changing rapidly. Similarly, web forms have a lot of promise but they aren't implemented well yet.
- Problems and all, HTML5 is now in use in many places and it is being pushed by Google, Apple and other big players. Browsers are implementing parts of it.
- This is a page to study, there are many examples there for just about every situation.
- Charset no http-equiv="content-type" content="text/html" Script no type="text/javascript" link no type="text/css To start using HTML5 today, all you have to do is change your DOCTYPE. HTML5 supports existing content, which means that it's backwards compatible.
- Part of backwards compatibility Obsolete: frame, frameset, noframes, acronym, font, big, center, strike If you want to support XML, you can write HTML5 with the same rigor that you used to write XHTML and it will work
- I think a practice that includes rigorous, well-formed syntax is the best idea, but it's now a matter of personal preference.
- These new definitions of old tags that were presentational give them a semantic underpinning for the first time, which means they are more accessible.
- Actually, you don't really need the head and body tags in HTML5. They are considered to be understood in an HTML5 document and a page without them will actually validate. Personally, I choose to err on the side or rigor in the code, so that's what I'll be showing you here. Just be aware that you can get by with less and still be writing valid HTML5.
- Of these, audio is fairly useable right now. Video requires fall back content in several different file formats such as ogg or swf. Canvas draws with JavaScript. Canvas currently has accessibility issues, even though every browser except IE8 and below support canvas.
- These new elements are the most useful right now, the easiest to make accessible, and the ones we'll concentrate on in building a page together today. Two other helpful new semantic elements that don't fall into the sectioning content area are figure and figcaption
- These are not implemented well cross browser yet, but some have promise in terms of usability and accessibility. They aren't ready to use yet.
- .This is a good place to start using HTML5. You can try out the new semantic sectioning elements. We'll build a page using these new elements to see how it works. We'll look at it in visual browsers, where things often work. That doesn't mean they would work the same way in assistive devices.
- It's more complicated than this, but you can see how the layout could be built. The area I have marked as an aside could also logically be a section instead. Aside means content that is tangentially related, so you would decide which to use based on your particular content. Right now, most AT devices don't distinguish between these new semantic elements and the familiar DIV. You can see the specifics for each one at HTML5accessibility.com. This website also has a workarounds page, listing ways to make HTML5 accessible right now. A major way is ARIA roles.
- Only the first heading in an hgroup element appears in the document outline using the new HTML5 outlining model. I have a link to a site that will outline your HTML5 documents for you. The fact that h1 elements can be used multiple times on a page is counter intuitive to everything we've known so far. It's a big change. Hgroup has been in and out of the spec. There's discussion about it right now which should be concluded by May 22, 2011. We'll act as if it's in, but it may not end up being in. See http://html5doctor.com/the-hgroup-hokey-cokey
- Browsers can't display this properly yet, so we'll modify it, but it's in the current spec like this.
- Accessible Rich Internet Applications Suite (ARIA), defines a way to make Web content and Web applications more accessible. It is used to improve the accessibility of dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. ARIA roles work now in many browsers and screen readers. When they don’t, they are harmless. If you build a page as accessibly as you can and then add ARIA roles into it where possible, you increase the potential accessibility of the page. It isn't perfect yet, but it does help in some cases.
- Adding ARIA roles to the HTML5 semantic structural elements adds needed accessibility.
- You can also add IDs for CSS purposes. Banner can only be used once per page. In theory, you should be able to wrap the anchor tag around both the logo image and the h1, but that doesn't display right in any browsers I tested yet, so I'm showing it to you this way.
- Writers like Jeremy Keith and Tantek Celik are suggesting that bulletproof HTML5 for current implementation and styling should use nested divs with a class name that matches the element name. I'm not going to show it to you that way today, but feel free to try it that way or to include examples of it in your individual work.
- For example, ARIA landmark roles make navigation on AT much easier. So even when the HTML5 elements are recognized, ARIA still adds value. Window Eyes, according to HTML5accessibility.com has issues with some landmark roles with some HTML5 semantic elements.
- People are a little unsure about their footing with articles and sections, it's one of the parts of HTML5 that seems confusing.
- Essentially, this is replacing a lot of what we did with divs.
- If you think of a blog post as an article, it could contain a header, some content divided into sections with headings, some nav areas for permalinks or comments, the comments might be asides or sections. Taken all together the article is something that you could use as a single piece.
- Furthermore, each article might have sections. The aside might have sections. To get the visual display to style, I wrapped the whole layout in a div with the id=wrapper
- The bare bones of the structure.
- Add the ARIA role. You can also add ID or class identifiers for CSS and JavaScript hooks.
- Eventually this will be a section in the aside. Go ahead and mark it up as a section, but keep it out of the way for now.
- Since articles will be used frequently, it's a good idea to assign them to a class.
- Alt text: lots of drama around whether alt text should be dropped completely or retained. It's been retained, but there is now a 40 page document explaining when to use it. Basically it is still there to do what it's always done, explain an image for those who can't see it or say nothing if the image is merely decorative. However, there are cases when the image is explained in the new figcaption and the alt text is not needed. Sometimes the image is explained in a title attribute, and there may not be a need for alt text then. My advice is to evaluate the need for good alt text on a case by case basis.
- An article footer could contain all sorts of things, these are just examples.
- The h3 in the aside could be in a header element. You would probably want to assign a class to the aside for styling purposes. The current wisdom is that if you only have one heading element, as in this aside, there is no need to wrap it in a <header> element. When you add a secondary heading or other material to the <header>, then the <header> wrapper becomes needed.
- Don't forget the ARIA role.
- I hope you've gotten the idea from the previous exercise that as aside is not necessarily a sidebar, although it can be. Let's move on to that next. Depending on how you wanted to lay out the page, you might want to insert the source material for the aside before the maincontent as I did in the example that is styled.
- Give it an ID
- Include the ARIA role.
- You can add additional sections, a nav area, articles, etc. What do you not see in this example that could be included? (heading element)
- Let's build one of those traditional footers.
- Since the page footer will be a unique footer on the page, you can give it an ID. The ARIA role 'contentinfo' can only be used once on a page and indicates the section of the page where information about the page is contained: legal notices, copyright information, etc. It's become a trend recently to put all sorts of things in the footer and build out a big footer with lots of peripheral information. That might be more appropriate in an aside that sits above the footer if you are using role=&quot;contentinfo&quot; with the page footer
- Insert that script into the document head
- The only visual browser that comes close to displaying most of these is Opera. They are the least ready for prime time of everything we've looked at today. Even so, they have to most potential to improve accessibility – so we'll look at building them although we won't see much in the browser. Most require the addition of ARIA and additional widgets like those listed at http://www.html5accessibility.com/index-aria.html So far noone supports color, so I won't show it to you.
- The Placeholder text appears in the field. When someone clicks in the field, it disappears. The autofocus, new in HTML5, attribute replaces the scripted focus used now. With required, new in HTML5, the browser will check to be sure required fields are filled out.
- Browsers will autocomplete by default. You can turn off autocomplete for an entire form using the value &quot;off&quot; in the form element. You can disable autocomplete for individual form elements.
- When datalist displays in the browser, you can type in a value that isn't on the list.
- If the browser doesn't understand this, it simply displays a normal input text field. With a label, it's perfectly useful right now.
- These are especially helpful in mobile devices, where the on screen board is different depending on the type attribute. For example the keyboard for an email address would include the @ sign, the keyboard for a phone number would be a number display, and the keyboard for a url would include the forward slash and a .com button.
- Browsers that don't support the date input type will display a regular text input. You would have to ask users to enter the date manually. Of course there are many existing JavaScript widgets that do this, which might be a better way to go until all the browsers implement the date input type.
- Here's a tutorial about building cross-browser forms that uses scripted support from Webforms2 , Modernizr , jQuery UI Even when you go to all that trouble to use HTML5 forms, that doesn't necessarily mean they will be more accessible in AT devices.
- This web site also has tables for the new input types and other new form elements as well as information about JavaScripts and CSS with HTML5 forms. In the resources section, there is a link to http://www.accessibleculture.org/research/html5-aria-2011/ HTML5, ARIA Roles, and Screen Readers in March 2011 | Research | Accessible Culture