Category Archives: Standards

HTML5 Tips: structral elements, Doctype and ARIA

My site is well overdue a face lift flavoured with HTML5, a dash of ARIA and a healthy dose of WCAG 2.0. As you’d expect playing under the hood with all these things has made me ask a lot of questions so I thought I’d post a few tips along the way that I’ve found  have helped with the redesign process (more of which later).

So without further ado:

  1. The <header> element can be used multiple times on a page and can contain site <nav> and search.
    The <header> element is typically used on every page for the site header and contains an <hgroup> of site name as H1, site tagline as H2 and a logo. Bundled into the <header> you can also add your primary <nav> as well as search.  As the HTML5 specification says:

    The header element represents a group of introductory or navigational aids. A header element typically contains the section’s heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.

    Note that <hgroup> only really only makes sense when there is a group of heading information (site name, tagline, logo) and is not appropriate for single headings.

  2. The <nav> element and primary navigation
    In the HTML5 specification <nav> is defined as follows:

    The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element.

    There has been a lot of discussion around what “major” navigation means (site, section, in page navigation, related links?) and what can legitimately be wrapped in the element and what can’t. General thinking is that “major” refers to global site navigation (About, Services, Products, Contact) as well as sub-navigation. Secondary navigation such as related links or grouped links of resources would not qualify for <nav>.

  3. <footer> can be used multiple times in a page.
    Typically you’d expect to use a footer at the end of a page housing your copyright and site design information and other bits and pieces. <footer> can also be used for footer information for any section you are in within a page. For example a common usage may be at the foot of a blog post – itself contained in an <article> – containing information about tags, categories, author, comments and date/time information. The HTML5 specification explains <footer> as follows:

    The footer element represents a footer for its nearest ancestor sectioning content. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

    Note that the <footer> element can not contain any other sectioning content such as <nav>, <section>, <header> or <footer>.

  4. An <article> can appear within an <article>.
    Possibly one of the more obvious tips but worth a mention anyway. The <article> element is a container that can in turn contain many parts. For example on a blog posts contained within an <article> you may have another <article> housing comments. Designing a blog post with HTML5 from HTML5 Doctor has an excellent overview of this.
  5. Using <!DOCTYPE html>
    The new Doctype in HTML5 is much simpler – and memorable – than previous Doctypes.  <!Doctype html> will render content in standards mode by all modern browsers (IE, FireFox, Opera, Safari) while the good news is that all pre-HTML5 Doctypes are still valid.
  6. HTML5 can be used with WAI-ARIA.
    HTML5 and ARIA certainly cross over but should not be seen as contenders. At the moment there is not much know of screen reader support for HTML5 given that the screen reader vendors themselves have not been visible in the development of the spec. This may well be because they are ll racing to implement ARIA which is a priority at this point. This makes sense given that the ARIA is in Last Call – the final stage a specification goes through before it becomes a W3C specification – and as such will be a reality sooner than HTML5.
  7. (Update) HTML5, IE and Firefox 2
  8. IE and Firefox 2 lack native support for structural elements so you’ll need to add in some JavaScript to make it work. In IE you add the following to the head to get IE to behave:

    <!--[if lte IE 8]>
    <script src="html5.js" type="text/javascript"></script>
    <![endif]-->

    Firefox 2 and Camino can be fixed using JavaScript or by serving Gecko XHTML. Getting HTML5 working on IE and Firefox 2 from HTML Doctor has a good article about how to do this.

    This obviously has a baring on whether you want to use HTML5 in your site or not yet. Given FireFox 2 has a tiny market share (most Firefox users upgrade fairly quickly) it’s really your call. The same can’t be said of IE however. I think this is why we are seeing more HTML5 sites in personal websites and blogs rather than corporate websites which have more at stake.

  9. Declaring HTML5 elements
    Most modern browsers (Firefox 3+, Safari 3+, Opera 9+, Chrome 1+) are yet to recognise section elements which means problems when laying them out in CSS. To get sections to display properly always use display:block in the CSS:header, nav, section, article, aside, footer {display:block;}

Resources

Being a hot topic right now there are reams of resources and tools being built that cover HTML5. This is my pick of a few that are well established, consistently useful and updated regularly:

  • HTML5 Doctor - Articles and tips covering  HTML5 and its semantics and how to use them. You’re also invited to submit questions for the HTML5 Doctors to answer.
  • HTML5 Gallery – a showcase of sites using HTML5.
  • HTML5 cheat sheet – A PDF of HTML tags and attributes together with brief explanations.
  • HTML5 differences to HTML4 – a W3C resource that does what it says on the tin.
  • Bruce Lawson – one of the brains behind HTML5 Doctor as well as the ultimate HTML5 cowboy forging ahead with implementing HTML5 and sharing his findings as he goes along. Follow @brucel on Twitter too.
  • Remy Sharp – Remy’s blog covering things HTML5.
  • HTML5  demos – set up by Remy Sharpe who focuses on JQuery and HTML5 this is a repository of demos looking at more of the application side of HTML5.
  • HTML5 Outliner – a nifty tool from @gsnedders that outlines structure in HTML5.
  • The Paciello Group blog – for the more ARIA minded developer with some HTML5 on the side.

And of course, last but not least the HTML5 Specification.

Opera BBQ, @Media, Standards.Next and HTML5 Doctor

Last week was one of those busy weeks which was all about conferences and meetups and not a moment of desk time inbetween.

Bruce Lawson does kewai

Bruce Lawson does kewai

Molly Holzschlag and Espen André Øverdahl

Molly Holzschlag and Espen André Øverdahl

We kicked off with an Opera BBQ on Wednesday followed by @Media, then rounded off with Standards.Next on Saturday. All in all it was a very HTML5 themed week  and thanks to a brilliant mix of people I learnt a lot and finally met some people who I’ve been chatting with over Twitter for some time now.

@Media

@Media rocked and ended on a high note with the announcement that Maxine Sherrin and John Allsopp would be taking over organisation of the event under the Web Directions monika. After so many rumours that 2009 was to be @Media’s last this was a more then welcome thing to hear. A hat tip and huge thank you to Patrick Griffiths’s for building @Media into what it is today.

Jason Santa Maria and Jon Hicks (avec a fetching tash) during the Hot Topics panel

Standards.Next

For me though the highlight of the week was the first ever Standards.Next meetup focusing on HTML5 – the big news so far to come out of 2009 (well at least I think so). We had roughly 60 people show up to help us chew the fat over HTML5, myths, canvass, APS’s, HTML5.js and accessibility. Thank you to all the speakers for making the event more than Bruce and I could have hoped for and also to everyone who showed up on what was a beautiful summer’s Saturday.

Below are a few links for those that didn’t make it and I’ll keep you updated as to when we post video of the event:

  • Bruce LawsonHTML 5: Are you mything the point? (.ods, 1.8 M), also on video. Yes you can start using some of HTML5 now, browser vendors aren’t evil, no HTML5 wont kill Flash, Silverlight and JavaScript and HTML5 does love accessibility (it’s just built in not bolted on).
  • Dean Edwards – Dean presented his excellent html5.js library which will be available soon but you can get a sneak peek on video here. He demo’d implementations of Web Forms 2 that worked across browsers even adopting accessibility settings from the OS for some. An amazing piece of work.
  • Remy SharpHTML5 JS API’s (PDF), demos and video. How JavaScript and HTML5 can play nicely together. With HTML5 taking care of the more mundane uses of JavaScript (date pickers and validation for example), JavaScript Ninja’s can now spend time on the more sophisticated stuff.
  • Martin KliehmHTML5 and Canvas slides, links and video shorts. Martin is the go to man for canvas and presented some great research and use cases that go beyond shoot-em-out games and Etch-a-Sketch.
  • Steve FaulknerHTML5 accessibility. The Mighty Steve Faulkner talked about accessibility issues as well as the relationship of WAI-ARIA to HTML5.
werqwerqwerwer

Andreas Bovens, Steve Faulkner, Patrick Lauke, PPK and Bruce Lawson during the break

HTML5 Doctor

An extra bonus was the launch of HTML5 Doctor, a collaboration between Rich Clark (of HTML5 Gallery), Bruce Lawson, Jack Osborne, Mike Robinson, Remy Sharp and Tom Leadbetter.

Next for Standards.Next

Plans are yet to be firmed up but we’re looking at doing cognition and accessibility Saturday 19th of September just after Techshare. If you’re interested in speaking or coming a long check the standards.nextwebsite for updates, we’d love to have you come along.

Update 29 June, 2009: Big thank you to Remy who’s managed to video Bruce, Dean’s and his own talks:

Standards.Next – HTML5 meetup Saturday June 27th

Standards.Next is a series of meetups around the latest technologies used in front-end development for the web. First up is HTML5.

We’ll be meeting, Saturday June 27th, the day after @Media featuring short talks on the nitty gritty of HTML5, tales from the frontline, the controversies, the agonies and the ecstasies. There’ll be beer on tap at the well loved Bricklayers Arms, just off Tottenham court road, London.

Speakers include Speakers include Dean Edwards, Steve Faulkner, Bruce Lawson, Molly E. Holzschlag, Remy Sharp and myself (if I can get a word in edgeways with that stellar line up).

Topics will include what you can use in HTML5 today, JavaScript APIs, HTML5 and WAI-ARIA integration, accessibility and some exciting announcements.

Signup at standards-next.org, stay tuned for more meetups to be announced (WAI-ARIA, webfonts, SVG anyone?)

ActiveX and the decline of Korean monoculture?

Not long ago I wrote about Google Chrome’s proposal to include ActiveX in the Korean market. This seemed like a transparent attempt to gain browser market share in a country where, due to government regulations, websites are locked into using Internet Explorer and ActiveX to carry out ecommerce.

In a press release from February the Electron Times (link in Korean, translation English pasted below) reports that Korean government is going to relax government website’s reliance on ActiveX. This is great news as it opens up choice for users in terms of what browser they can use, supports web standards, accessibility and innovation born out of competition.

All good news but for a couple of significant points – it only relates to government and proposes plugins as a solution.

Government only

As these changes relate only to Government websites the all important banking and e-commerce sites can stay as they are.  Changes will undoubtedly take time for government and while it’s hoped that this will influence non-government websites there is no guarantee.

Looking at lessons learnt from Section 508 in the USA – which mandated US federal governments to procure accessible technologies and build accessible websites – I’d say that this is not as far reaching as it needs to be. Yes, technology vendors such as Adobe have been forced to make their products accessible in order to retain US government sites as clients, but is that enough? One wonders why this stops with government websites but maybe I’m asking too much. Some change is better than none and we have to start somewhere I guess.

I spoke to a colleague in Korea and it seems that

ActiveX to be replaced by plugins

Secondly, rather than drop ActiveX entirely the proposal is to use a plugin, or a “keyboard security
module” that can be used in various other browsers. It seems a little odd to claim a “move towards web standards” whilst the solutions being implemented are are decidedly non-standard. I wonder if this will also just lead to more work in the long run as various plugins have to be built for various browsers – including mobile.

I’m also curious to know what browsers make the list of supported browsers. Given that IE usage is well above 90% there is little useful data to shed any light on non-IE browser usage. The Korean government could look towards other governments to see how they handle browser support such as the UK Browser Testing Guidelines that stress the importance of supporting standards-compliant browsers.

Added to this how will viable a solution it is expecting the average user to download and install plugins to make sites work in new browsers? Not very would be my guess.

A Google Chrome whitelist?

There has been talk of Google Chrome creating a white list of important sites that work in Chrome despite their reliance on ActiveX:

However, Google is not intending to miss out on the Korean market and said it is planning to make Active-X operate on Chrome for a designated number of Korean sties.

While this was reported in the Korea Times last September a colleague informs me that Chrome does not yet support this whitelist. So far so good, but what concerns me is that Google is opting to effectively endorse ActiveX by providing a work around rather than influence a move away from ActiveX.

Lois Kim, head of corporate communications and public affairs Google Korea, sees it as doing Korean Netizens a favour:

We don’t intend to make Chrome inconvenient to Korean Internet users.

I really can’t see it that way. Who defines this whitelist – the user, the website owner, Google? And how is it going to work with the proposed plugin? It just promises to get messy and yet again users lose out because this “fix” is temporary and essentially flawed much as the Microsoft IE8 opt in to standards mode switch is.

Looking ahead

In 2007 Gen Kanai asked what the cost of monoculture would be on a country that has to date been so locked into using one browser. In 2009 I think we’re seeing some of the fallout as there is clearly no easy route to opening up the Korean web space.

Much of the problem seems to be down to political conflict between government departments a colleague in Korea tells me. The press release below references the Ministry of Public Administration and Security’s (MOPAS) efforts to put in place a task force for standardization of government sites. This has been widely seen as a good thing however they have no jurisdiction over internet security and are limited in what they can do. Differing interpretations of regulations and differing attitudes of security software vendors stand well in the way of easy resolution.

Such political wranglings have not deterred standards advocates such as Professor Kichang Kim of Korea University pursuing a law suite against Financial Telecommunication & Clearings Institute (KFTC) for overwhelming use of ActiveX. Twice he has lost and is waiting for a ruling on a third case. He is part of a Korean Open Web movement who have been pushing for standards and accessibility law which came into affect April 11th so persistence does pay.

I hope that eventually the requirement to make websites work in other browsers extends beyond just government and does not rely on yet another non standards solution such as a plugin. It may be that the harsh reality is that putting pressure on commercial websites to change is difficult whereas creating laws and bringing lawsuits against government is easier so change needs to start there. Given my experience in the UK with government websites under a firmer directive to be accessible perhaps there is something in it.

Is it also too much to hope that Google has seen sense and is not going to go down the route of whitelists? We’ll have to wait and see. In the meantime let’s hope that Professor Kichang Kim’s current lawsuit is favourable – perhaps this could stop Google moving forward with their plans,

English press release from the Electronics Times: Dismantling Barriers among Internet Browsers

Posted 23th, Feb, 2009

The government is launching on an effort to promote web standards that
will allow unrestricted access to the Internet from all browsers including
Internet Explorer, Firefox, and so on.

A government division announced on Sunday that the Ministry of Public
Administration and Security plans to establish a policy to promote web
standards and enforce standard application by setting the current
condition of websites as evaluation criteria of information level.

Last April, the government enforced application of web standards for new
websites of administrative agencies and local governments, based on the
guideline for observation of web standards. This time, the scope of
enforcement will expand to cover existing websites.

With application of web standards, Internet will become accessible to many
more browsers such as Firefox, Safari and Opera, in addition to
Microsoft’s Internet Explorer.

Until now, various Internet services have been developed separately, which
were criticized for lacking compatibility and accessibility. The
government will enforce the standard starting from the government web
services.

An insider of the Ministry of Public Administration and Security said that
the affiliated agencies and local governments will be forced to observe
web standards, and even though it will be hard to force the same to public
organizations, they will be requested to diagnose state of their websites
and to disclose the result to have a motive for improvement.

The Ministry of Public Administration and Security organized a task force,
with participation of developers, browser company managers and other
experts, and had five meetings so far in order to establish web standards
observation guideline. The Ministry is considering organization of a
committee that will conduct regular technical review.

Korea Communications Commission (KCC) recently launched on developing
keyboard security module, following development of Firefox certificate to
enable Internet banking on other browsers than IE. Internet banking on
Firefox has not been realized because the security module did not work on
the browser. To solve the problem, KCC plans to develop keyboard security
module for various browsers. An indiscriminating module will be applied to
certificate by the end of this year so that it can work regardless of
types of browsers.

Oh Sang-jin, section chief of KCC, said even though a number of people
that use browsers other than IE are insignificant, KCC decided to develop
keyboard security module to allow more people to access Internet service.

Trying to explain web standards to my Mum

None of my home or university mates work on the web and I’m often asked “But what is it you actually do?” to which I reply “Web standards” and give as good an explanation I can normally along this lines of “Buildings have to be built to standards right? Well so do websites…”.

I normally get muted nods and I think my Mum has just given up.

Fail enough really because as far as they’re concerned what I do is non-standard; I’m not a film maker, writer, retailer, doctor, project manager or any of those professions that have been around a while.

In this video, Jeffrey Zeldman, who founded the Web Standards Project, explains what web standards are, why we have them and why they benefit website owners, developers and users alike.

Over to you Mr Zeldman…

Why UAAG needs you (oh no not another set of guidelines)

With just under two weeks to go until the call to review the User Agent Accessibility Guidelines 2.0 (UAAG) closes (April 22nd) I expect you’re all heads down going through the spec like things demented…ok, possibly not.

Working for Opera I’ve just joined the UAAG Working Group and have started to look at the guidelines properly for the first time in ages. This is not my natural area as I’m a content person through and though and therefore much more familiar with the Web Content Accessibility Guidelines (WCAG). So it’s got me thinking would a developer, a website owner, a user or a software procurement person really want to get their hands dirty with UAAG?

So this is what I came up with that made sense to me:

  1. You develop accessible content. UAAG is just one of three sets of guidelines relating to accessibility produced by the W3C the other two being the “celebrity” Web Content Accessibility Guidelines (WCAG) and the more “D-List” (but up and coming thanks to social networking) Authoring Tool Accessibility Guidelines (ATAG). All share interdependencies and are designed to work together so that browsers (UAAG) render content (WCAG) that has been authored and tested (ATAG) for accessibility.
    If one component is weak it can result in your content (that you have made accessible according to WCAG say) unusable. Think for example of the amount of times you hear “But this browser works differently from that browser” or “screen readers haven’t caught up yet and can’t handle such and such”. As a developer you have to spend more time developing workarounds to compensate for the browser and/or assistive technology. Not something that anyone relishes.
  2. You’re interested in developments with HTML5. With so much discussion around what is relevant to the browser implementors and authors it’s useful to see where the lines blur between browsers and authors. HTML5 is attempting to do much that the author has had to do themselves before such as forms validation, support for video and audio, datagrids and so on. Previously these would be done by the authors using scripts meaning more work and less consistency for the user across websites. This is turn leads to a wider margin for error to allow inaccessible content and poor usability.
  3. You build plugins or extensions. According to the UAAG FAQ these too are also user agents and therefore have to follow the principles of keyboard access, rendering content accessibly and communicating with assistive technologies. So if you’re into building extensions for Firefox then you’ll need to ensure accessibility.
  4. You develop web applications. Ok, so this is more of a controversial one but there’s nothing wrong with that. I’m also curious to hear what people think. So here’s the question: when does web content morph into being a web application and become better defined as a user agent rather than web content? For example, Easy YouTube is a skin for YouTube designed to make playing video easier for people with cognitive problems. As such it can also be defined as a media player which sits very much under the user agent definition.
    This is a tricky because it’s doubtful that any developer is going to seriously look at following both WCAG and UAAG when developing. You can also argue that if you were able to upload, and therefore author, content to Easy YouTube the developer could find themselves having to reference UAAG, WCAG and ATAG.
    Back in the real world I think this is asking way too much but there is something of a cross over. It may be that WCAG is sufficient covering key aspects such as device independence and keyboard access but understanding the relationship would be useful. I wonder if anyone has done a mapping of UAAG, WCAG or ATAG…
    The UAAG working draft does specifically ask what people’s thoughts are on web applications:

    “Does the inclusion of Web applications (e.g video players, email clients, document applications) in the definition of user agents add undo burden or conflicts? What distinguishes Web application user agents from Web applications that are not user agents?”

    So leave a comment if you have any thoughts.

  5. You’re a user. Being a user of assistive technology I would be keen to ensure that content worked for me. Understanding all three sets of guidelines means you’ve got a better idea of why something doesn’t work and how it can be fixed. This will help you to both flag problems to the vendors of user agents as well as inform decision as to which browser, media player and assistive technology you use.
  6. You’re in procurement. If you are someone who makes decisions about what software to purchase you’ll need to know which software meets you accessibility requirements. Being able to do a comparison against UAAG, or to be able to ask for compliance to UAAG in tenders can help safeguard accessibility concerns.

So I’m sure you’re all convinced that you need to look at UAAG right away so I wont hold you back with any more chatter from me. Details about how you can comment on UAAG are available from W3C together with an overview of UAAG and the draft UAAG 2.0 in all its glory.