The current accessibility support implemented in browsers lags behind their implementations of the sexy new features themselves. These are still early days in the implementation of HTML5 features, so lets keep our fingers crossed that Google, Apple (Safari on Windows) and Opera will get their acts together to provide at least a basic level of HTML support in their browsers for assistive technology users. Equally it is hoped Mozilla, Apple (Safari on Mac) and Microsoft will strive to have their rate of accessibility support match their rapid implementation of the new HTML5 features.
To address the need for standardizing the implementation of accessibility features, Steve and others have begun working on the HTML to Platform Accessibility APIs Implementation Guide.
We can’t thank Steve enough for his work on this and wish him well as these efforts continue.
]]>Excerpt from the 3rd Annual Blue Beanie Day Event Page:
It’s easy to show your support for web design done right. Beg, borrow, or buy a Blue Beanie (or Blue Toque in Canada) and snap a photo of your mug wearing the blue. (Or get creative with Photoshop). Then on November 30, switch your profile picture in Facebook, Twitter, Flickr, (and any other social network) and post your photo to the Flickr Blue Beanie Day 2009 group.
Want to help with planning the 3rd Annual Blue Beanie Day? Planning a meetup or tweetup in your hometown? Organizing a group photo in your city? You might qualify to win a free copy of Zeldman and Marcotte’s (brand new) Designing With Web Standards 3rd edition. Contact Douglas Vos.
Kevin Cornell makes it even easier for us this year by providing an illustrated blue beanie photoshop file.
So don a blue beanie, spread the word and keep working towards a truly open web.
]]>Accessibility Task Force member, Bruce Lawson, interviews Hixie on how the specification for the next generation of the Web’s markup language is shaping up. Disclosure of affiliations: both work for browser vendors—Bruce for Opera, Hixie for Google (and previously, Opera and Netscape).
Bruce
The spec now known as HTML 5 began with a "guerilla" group called WHATWG. How and why did the WHATWG begin?
Hixie
The short answer is the W3C told us to.
The long answer: Back in 2003, when XForms was going through its final
stages (the "Proposed Recommendation" vote stage), the browser vendors
were concerned that it wouldn’t take off on the Web without being made a
part of HTML, and out of that big discussion (which unfortunately is
mostly hidden behind the W3C‘s confidentiality walls) came a proof of
concept showing that it was possible to take some of XForms’ ideas and put
then into HTML 4. We originally called it "XForms Basic", and later renamed
it "WebForms 2.0". This formed the basis of what is now HTML 5.In 2004, the W3C had a workshop, the "The W3C Workshop on Web Applications
and Compound Documents", where we (the browser vendors) argued that it was
imperative that HTML be extended in a backwards-compatible way. It was a
turning point in the W3C‘s history—you could tell because at one point
RedHat, Sun, and Microsoft, arch-rivals all, actually agreed on something,
and that never happens.The outcome of that workshop was that the W3C concluded that HTML was
still dead, as had been decided in a workshop in 1998, and that if we
wanted to do something like HTML 5, we should go elsewhere. So we announced
a mailing list, and did it there.At the time I was working for Opera Software, but "we" in this case was
Opera and Mozilla acting together (with Apple cheering us from the
sidelines).
Bruce
How did you become editor?
Hixie
I was at the right place at the right time and everyone else was too busy.
Bruce
How do you personally go about editing the spec and incorporating
feedback? What are your processes?
Hixie
This has varied over the years, as we’ve gone from a nascent organisation
with a few dozen people to a well-established project with a mailing list
with 900+ subscribers. Mostly it’s all down to managing e-mail. When
someone writes feedback on the spec, whether by sending an e-mail to one
of the mailing lists I’m on, or by blogging somewhere, or twittering, I
log their feedback in a folder on my IMAP server. Feedback gets
categorised into either feedback I can work on right away, or feedback
that I can’t deal with yet for whatever reason. An example of the latter
would be requests relating to mutation events, because I’m waiting for
DOM3 Events to update how mutation events work.Then, I just go through all the feedback I have, e-mail by e-mail, more or
less in the order that I received them, sending replies and fixing the
spec to address the issues that were raised.This has some disadvantages, for example there’s a big delay in between
when someone spots an error and when I fix it. It also has some really
important advantages. If I respond to feedback on something I wrote
straight after writing it, I sometimes find that I have an attachment to
that section, so if someone suggests a total replacement, I tend to not
like their idea. But if I have a delay, I find my attachment has gone
away, and I’m eager to replace my old stupid idea with their better one.
(Assuming it’s better, anyway!)
Bruce
What’s the hardest thing to do?
Hixie
There are a few things that are hard. One is saying "no" to people who have
clearly spent the time to come up with a good idea. The sad truth is that
I reject almost everything that I and anyone else thinks of, because if I
didn’t, the spec would be a thousand times more bloated than it is now. We
get proposals for all kinds of things, and we have to have a very high bar
for what goes in. There’s also the danger that if we add too many things
to the spec too quickly, the browser vendors will each implement their own
bit and it’ll be a big mess that won’t help Web authors.So I have to make judgements about what is worth adding and what isn’t,
and that’s hard. I’ve upset a lot of people by rejecting their ideas,
because they take it personally. On the other hand, some of the most
productive members of the community now are people who’ve had many of
their ideas rejected, but they stuck around long enough to see a few of
their ideas make it in. The best way to get an idea into the spec is to
find something in the spec that’s just clearly wrong, which is something
that a lot of the most active people do a lot, too!Something else that’s hard is making up new features. The bulk of HTML 5 is
actually just defining how browsers already do things, which, although
complicated and sometimes unbelievably arcane, is, at the end of the day,
pretty easy to spec: you test the browsers, and you write what they do.
Rinse, repeat, until the spec covers every possible case.Making up new features, though, means actually thinking about what should
happen, what is the most understandable solution, figuring out how things
should fit together, and so on. It’s often tempting to make something that
is theoretically neat, but which doesn’t fit in with the rest of the
language, too. After all, that’s where all this came from—we don’t want
to create a new XForms, a really well-designed technology that doesn’t fit
into the way people write pages.
Bruce
You’ve said that HTML 5 is in "direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight". Why is it so important to do so, and isn’t it a lost cause given that those techologies are already out there while HTML 5 is not yet complete?
Hixie
HTML 4 is also in direct competition with proprietary technologies, and
it’s winning, hands-down. HTML5 is just continuing the battle, because if
we don’t keep up, then the proprietary technologies will gain ground.
Bruce
What are the main philosophies of HTML 5?
Hixie
Backwards-compatibility, incremental baby steps, defining error handling.
Those are the main philosophies.
Bruce
What else did WHATWG try to achieve with this new iteration of HTML?
Hixie
We started from trying to put features from XForms into HTML 4, and we
quickly also took the opportunity to fix some of the things in HTML 4 that
were either too vague or disagreed with reality (that is, where the
browsers all did one thing but the spec said another). It turns out that HTML 4 is so vague that this is a pretty big task—it even involved
defining the whole HTML parsing model, including error handling, which is
a huge job (it took me the better part of a month to write the first
draft, and we were tweaking it for about a year before it become more or
less stable).Something else we’ve tried to do is make things simpler. We’ve simplified
the syntax (e.g. the rules about what can be quoted, what strings are
validids, etc, are much simpler now). We’ve made things which people
used to do in JavaScript have shortcuts, so now you can just sayautofocus=""to focus a form field when the page loads, instead of usingcontrol.focus(), which allows the browser to do clever things like not
actually focus the control if the user is already typing elsewhere.
Bruce
Does HTML 5 legitimise tag soup? Does "paving the cowpaths" perpetuate
bad markup?
Hixie:
No, HTML 5 actually makes the rules for markup even stricter than HTML 4 in
many ways, both for authors (the rules are simpler, but stricter, than HTML 4′s) and for implementers (gone are the days where they can just do
whatever they want when handling parse errors, now every browser has to
act the same).Hopefully, we’ve managed to make the rules on what is valid syntax more
understandable, which should help with getting more good markup. We’ve
also made it possible to write clearer validators, so I have high hopes.
Bruce
Does including JavaScript and DOM APIs in the HTML 5 spec dilute the
message about separating behaviour and structure?
Hixie
I didn’t know about a message about separating behaviour and structure, I
must have missed that memo! HTML 5 takes a pretty hard line on separating
style and presentation from structure and semantics; there are no morefonttags. Separating the logic and behaviour from the structure and
semantics of an HTML document isn’t as important, generally, as far as I
can tell.The main advantage of defining the HTML DOM APIs and the HTML elements in
the same specification is that we don’t let stuff fall through the cracks.
In practice, browsers implement the HTML elements as DOM nodes, there’s no
difference. When we separate the two in the specs, therefore, we introduce
a conceptual gap where there isn’t one in reality. The DOM2 HTML spec, for
instance, doesn’t say what happens when you change thetypeattribute of
aninputelementfromtext tocheckboxon the fly, and the HTML 4
spec doesn’t mention that changing attributes on the fly is possible, so
in the HTML 4 / DOM2 HTML era, there’s a big hole there. In HTML 5, this is
all defined together, so we can tighten this up and make sure there are no
gaps.
Bruce
Why no native support for microformats/ RDFa in HTML 5?
Hixie
Microformats is natively supported in HTML5, just like it was in HTML 4,
because Microformats use the built-in extension mechanisms of HTML.We considered RDFa long and hard (in fact this is an issue that’s a hot
topic right now), but at the end of the day, while some people really like
it, I don’t think it strikes the right balance between power and ease of
authoring. For example, it uses namespaces and prefixes, which by and
large confuse authors to no end. Just recently though I proposed something
of a compromise which takes some of RDFa‘s better ideas and puts them into HTML 5, so hopefully that will take care of the main needs that caused
people to invent RDFa. We’ll see.
Bruce
Do the browser makers have too much influence on the spec?
Hixie
The reality is that the browser vendors have the ultimate veto on
everything in the spec, since if they don’t implement it, the spec is
nothing but a work of fiction. So they have a lot of influence—I don’t
want to be writing fiction, I want to be writing a spec that documents the
actual behaviour of browsers.Whether that’s too much, I don’t know. Does gravity have too much
influence on objects on earth? It’s just the way it is.
Bruce
One of the chairs of the W3C working group is a Microsoft employee. Is that giving too much power to one browser vendor, or a good thing,
given that Microsoft’s browsers still dominate and their buy-in on any spec is
therefore essential?
Hixie
Personally I would like Microsoft to get more involved with HTML 5. They’ve
sent very little feedback over the years, far less than the other browser
vendors. Even when asking them about their opinion on features they are
implementing I rarely get any feedback. It’s very sad. If I e-mail them a
question about how I can best help them, I usually get no reply; at best
I’ll get a promise that they’ll get back to me, but that’s it.
Bruce
There has been a lot of spirited debate (ahem) about accessibility in
the development of HTML 5. How does the spec deal with the requirements
of people with disabilities?
Hixie
Universal access—the requirement that anyone be able to use information
on the Web—is a fundamental cornerstone of HTML‘s design, just like
security, privacy, and so on. In general, we try to design features so
that they Just Work for everyone, regardless of how you are accessing the
Web. For example, in HTML 5 we’ve added new input controls like calendars.
These will Just Work with screen readers once browsers support them,
authors don’t have to do anything special.
Bruce
Does your personal support of humanitarian eugenics affect your opinion of giving
extra "help" for people with disabilities?
Hixie
You’ve been reading too much of our pet troll’s blog! ;-)
[Bruce's note: this refers to Mr Last Week, mysterious author of the blog Last Week in HTML 5, which lampoons the HTML 5 Working Group in very funny, frequently foul-mouthed manner.]
People with disabilities are just as important to me in my work on HTML 5 as is anyone else.
Bruce
You wrote to ask screenreader vendors to participate in
the specification process. Did they ever reply?
Hixie
A couple did, but only to say they had little time for the standards
process, which was quite disappointing. Since then, though, Apple has
ramped up their efforts on their built-in Mac OS X screen reader software,
and we do get a lot of feedback from Apple. So at least one screen
reader vendor is actively involved.
Bruce
HTML 5 and WAI-ARIA appear to do the same thing in some places.
How should developers handle this?
Hixie
When there’s a built-in way to do something, using that is the simplest
and most reliable solution. So for example, if you want to have a
checkbox, using theinputelement with itstypeattribute set tocheckboxis the simplest solution—it’ll work for everyone, with or
without JavaScript, with or without a screen reader, and so on. ARIA is
useful when HTML doesn’t let you do what you want and you find yourself
hacking around with many nesteddivs, scripting your own controls and so
forth.
Bruce
Can we expect ARIA-specific constructs which have no equivalent in HTML 5, such as live regions, to be allowed under the rules of HTML 5 so it will all validate?
Hixie
Yes, the plan is to make sure ARIA and HTML5 work well together. Right now
I’m waiting for ARIA to be complete (there are a number of last call
comments that they haven’t yet replied to), and for the ARIA
implementation rules to be clearer (it’s not yet obvious as I understand
it what should happen when ARIA says a checkbox is a radio button, for
instance). Once that is cleared up, I expect HTML 5 will give a list of
conformance criteria saying where ARIA attributes can be used and saying
how they should be implemented in browsers.
Bruce
Why would we content authors want to move to HTML 5? What’s in it
for us?
Hixie
Today is probably too early to start using HTML 5.
Long term, content authors will find a variety of new features in HTML 5.
We have a bunch of new structural elements likesection,article,footer, and so on. We have new elements for embedded media, likevideoandaudio. We have new input controls, like the calendars I mentioned,
but also fields for URLs, e-mail addresses, telephone numbers, and for
color selection. We have control over autocomplete values in text fields,
as well as field validation so that you can say which fields are required.
We have context menus,pushState()so you can update the URL in Ajax
applications, and offline application cache manifests so that your users
can take your applications offline. The list goes on.There’s also the benefits that come from using an HTML 5 validator. HTML 5
is much more precise about many things than HTML 4, so the validators will
be more useful in catching real errors. Theembedelement is no longer
invalid.
Bruce
Are there advantages for end-users, too?
Hixie
A more powerful HTML means more powerful Web applications. Just like
XMLHttpRequestresulted in more interactive apps, HTML 5 will result in
a richer and more consistently reliable experience. I hope!
Bruce
What’s the the timeline? When can we start using HTML 5?
Hixie
The plan is to have the spec mostly finished by October 2009. A lot
depends on the browser vendors, though. I don’t know when things will be
implemented widely enough that authors can use them reliably everywhere.
Some features, likecanvasandvideo, are getting implemented in most
browsers as we speak. Others will take longer.
Bruce
What can standards-savvy WaSP readers do to get involved with the specification process?
Hixie
There are a number of ways of taking part. What we need most of all these
days is technical review of the specification text, calling out places
where I screwed up, where the spec defines something that’s not easy to
use for Web authors, where the spec contradicts itself, typos, spelling
mistakes, grammar errors, errors in examples, you name it.I posted a blog entry recently detailing how people can send feedback. You can join the W3C HTML Working Group or the WHATWG. There are also lots of other things people can do—write demos, write tutorials, edit other related specs, write articles introducing parts of
the spec on the blog, write test cases… Anyone who wants to help out but doesn’t know where to start should drop
me an e-mail at [email protected].
Bruce
Will there ever be an HTML 6, or is it a convenient fiction to park
out-of-scope discussions?
Hixie
I’m sure there will be an HTML 6, and 7, and 8, and probably many more,
until someone comes up with something so radically better that we stop
evolving the Web as we know it.I expect work on HTML 6 will start even before HTML 5 is completely done, in
fact. Putting the finishing touches on HTML 5 will be a long and tedious
job involving writing a massive test suite. HTML 4 never had a serious test
suite created (it was too vague as a specification to really be properly
tested), so we have to start from scratch with HTML 5. The HTML 6 team will
at least be able to build on what we’ve done with HTML 5, I’m jealous!Actually if it was up to me, after HTML 5 I would probably transition HTML to an incremental model. Once we have a basic spec that is well-defined
and has been proven, instead of releasing a frozen snapshot every few
years, I’d prefer a model where we can slowly evolve the language, call it
"HTML Current" or something, without having to worry about versioning it.
To some extent that’s what we’re doing with HTML 5, but I think formalising
it would really help.Having versions of specs doesn’t make sense when you have multiple
implementations that are all evolving as well. No browser is ever going to
be exactly HTML 5, they’ll all be subsets or supersets. So why bother with
versioning the spec?It’s a very unusual idea in the standards world, so I don’t expect us to
do this. But I do think it’d be the best way forward.
Bruce
Would you like to be the HTML 6 editor?
Hixie
Too early to tell! It’s been a lot of fun working on HTML 5, it’s quite
challenging and you have to deal with all kinds of issues from the deeply
technical to the highly political. I might want a change of pace when
we’re done with HTML 5, though.
Bruce
What’s your fave feature that didn’t get into HTML 5 that you’d put
into HTML 6?
Hixie
In-window modal dialogs or dialog box—the kind of prompt you get when the
computer asks you a question and won’t let you do anything else until you
answer the question. For instance, the window that comes up when you say
"Save As…" is usually a modal dialog.Right now people fake it with
divs and
complicated styles and script. It would be neat to just be able to say
"make this section a modal dialog". LikeshowModalDialog(), but within
the page instead of opening a new window with a new page.I’d add it to HTML 5, but there are so many new features already that we
need to wait for the browsers to catch up.
Bruce
Finally, is it true that you and Mr Last Week are the same person, like Edward
Norton and Brad Pitt in "Fight Club"?
Hixie
Oh, no. Our pet troll is a phenomenon all to himself.
Bruce
]]>Thanks for your time.
Today the Protocols and Formats Working Group of the W3C has announced the Last Call Working Draft for ARIA. This means that the working group believes that this specification is ready to advance to the next stage. We’ll leave the specifics of the W3C Process to the W3C. What you need to know is that you have until March 24, 2009 to provide feedback to the W3C on the working draft.
Accessibility Task Force member James Craig was involved as part of the Protocols and Formats Working Group that has been working on ARIA; many thanks to James for all of his work on this!
Our own Henny Swan (International Liaison Group Co-lead) has put together some questions about the ARIA spec to get you kick started.
Also of note — commentary and criticisms of Safari 4 Beta abound. Did you take a look at the top of the Safari 4 new features list?
Yes, that’s right. Accessibility, including ARIA.
This isn’t something that is years off. This is something that is happening right now, before your eyes and it is important work for the future of creating accessible web applications, so dig in and have a read and provide feedback — even the small things count!
]]>Take it away Bruce!
I was recently lucky enough to travel around some universities in Indonesia, lecturing on emerging web standards as part of an Opera University Tour. In Indonesia, web standards are not widespread although interest is growing. One group who are really on the ball are the team behind the website of Institut Teknologi Bandung, a technology institute who hosted a lecture. I spoke to one of the team, Widianto Nugroho about his work, and standards in the world’s third most populous country.
Our team consists of five people, two web designers, and three programmers. We are responsible for development of web application of the ITB website as well as maintaining its day-to-day operation. Websites of other sub-units (faculties, schools, programs, offices, etc.) are run by each unit’s webmasters/admins. We work with other teams, such as the reporter team that is responsible for the content, and sys admin team that responsible for running the servers.
Tableless layout was implemented in 2004. Before that, we still used tables for layout purposes due to the lack of browser support before that time, but used valid tags and a proper doctype. We use web standards because:
Yes. standards make our web works better in any browser, and they give us a good foundation for developing our website in the future.
It is hard, trying to use standards in the beginning. After that, our job became a lot more easier with standards; we can make any improvement more easily.
No, not yet, but my team has proposed ITB to join W3C in the next year. I hope ITB can participate in the development of standards, especially for web technologies for developing countries.
I don’t know exactly, but some of web designers/developers and blogger activists that I know are very concerned about web standards. What could be done is through education and workshops about why web standards are important.
The biggest challenges in my opinion are:
No. In secondary school level, there is a vocational type of school that specializes in Informatics/Computer Science (Sekolah Menengah Kejuruan Informatika/SMK Informatika) where web design and development are taught. However, the content of the curriculum in this level is more concentrated on the Web in general, how to build it, and make use of the available tools/software.
The educational system currently employed in primary and secondary schools in Indonesia is decentralized in nature. With this system each educational unit (school) can tailor their own curriculum based on their localities, needs, etc. Hence, the implementation of the web design/development curriculum can be different from one school to another. It is similar to the higher education system; for example, in the Informatics Program here at ITB there is no course about web standards, neither is there in our Visual Communication Design Program.
In other places, most of the courses relate to the tools/software, programming languages and databases such as PHP/MySQL, or to particular platform such as .NET.
I believe that awareness of web standards is growing among web designers in Indonesia. However, I can’t yet say that all of the designers are using web standards properly. Some designers are submitting their work to CSS showcase such us the CSSmania.com, etc. This situation is supported by significant contributions by some individuals who promote web standards through blogs, mailing lists and forums.
There are some resources:
Influential bloggers that I know:
A huge thank you from WaSP and for taking the time to be interviewed, and for carrying the web standards torch in Indonesia!
]]>This was the feeling in Denver at the education-focus day “Ed Directions North” (held in conjunction with Web Directions North). The day included teachers from high schools, from colleges and universities and from industry. The premise was simple: bring together educators, web professionals and industry representatives to create a kind of think tank on improving the quality of education for the next generation of web professionals.
I say “we” but really I mean to say that there were a few key people that were involved in putting this together:
The tireless work of these people, especially Steph, Aarron and Chris with the hands-on work, and John for his support of the concept and the event combined with the work of Leslie Jensen-Inman and Bill Cullifer for their “Web Professional Education Summit” made for an excellent event with a focus on education like we haven’t seen before.
I was asked to share my expertise in accessibility (and teaching accessibility), others were there to share other specialties: Dave Shea, Mike ™ Smith, and Christian Heilmann (though I ended up delivering Christian’s slides on JavaScript as he got stuck in London with flight delays)
The bottom line? This was one of the most exciting events I’ve participated in. It was more than just a pre-conference. It was a group of people with a shared passion for education. It was enough to give me goosebumps, and others tell me they got an incredible buzz from it as well. This sounds incredibly corny to write, but on that day, we came away feeling like we really could make the world a better place. We had new friends, allies and conviction to improve the curriculum and teaching and learning materials for tomorrow’s web designers and developers.
This passion is what you’ll see when you come see the WaSP panel at SXSW and learn of the work that we’re doing on the education front. This passion is what you’ll see as we create our direction forward as the Web Standards Project. This passion is what you’ll see as WaSP implements a vision of improving and continuing education about web standards and accessibility best practices. I hope you share the passion that we do.
]]>WebAIM recently conducted a survey of preferences of screen reader users. With over 1100 responses, the results of this survey provide much useful information about screen reader user demographics and preferences. Some of the results were quite surprising. This comprehensive survey of screen reader user preferences provides much needed insight into this diverse group of screen reader users.
Here are a few findings:
- The most common screen readers used are JAWS (74%), Window-Eyes (23%), NVDA (8%), and VoiceOver (6%).
- 75% of screen reader users upgrade to the newest version within one year.
- 12% of respondents use a screen reader on a mobile phone.
- 76% of users always or often navigating by headings.
- 36% never or seldom use text-only versions of web pages.
- 72% of screen reader users reported that Flash is very or somewhat difficult.
There is much, much more to be learned about this diverse group of screen reader users at the survey results page.
It’s great to see some actual data and feedback from real screenreader users, instead of always hearing anecdotal evidence and generalised assumptions from designers and developers. As the disclaimer notes, the actual user sample was not controlled, some of the questions may have been too technical, and some responses may have been tainted by previous experiences with badly-coded and inaccessible sites.
Perhaps the most significant conclusion we can make from these survey results is that there is no typical screen reader user.
One thing I’d like to see in any future survey would be actual testcases that respondents are asked to evaluate, which may give more representative results. In the meantime though I’d like to thank the WebAIM team for their effort and look forward to the more in-depth analysis of the data gathered from this survey.
]]>These suggested that for government web sites, webmasters need not test in less popular browsers (those with less than 2% in that site’s usage statistics) and that there should be a page on the site listing the popular browsers which had been tested with the message “We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above”.
I called on readers to email the consultation address and object that the guidelines did not advocate web standards and methodologies like progressive enhancement to ensure that all browsers were served. The Register carried the story, and two days after I made that call, the author of the guidelines, Adam Bailin, commented that over 400 people had already emailed him.
Last Friday, 16 January, Adam published the revised browser testing guidelines, and he’s done a great job of including best-practice development. The guidelines point to the BBC‘s support table as a good example of graded browser support, and notes the importance of supporting standards-compliant browsers (paragraphs 17-18):
Coding a site to web standards should ensure that any browser that supports web standards will render and behave as intended. Therefore your browser testing matrix must include browsers that support web standards.
You should follow a progressive enhancement approach to developing websites to ensure that content is accessible to the widest possible number of browsers.
The importance of valid code is noted (paragraphs 21-23):
All (X)HTML content must validate with respect to your chosen DTD.
You must use valid CSS for the presentational layer of your website including layout and styling. (X)HTML tables should only be used for presenting tables of data.
Code used for adding richness to the user interface (e.g. JavaScript, ActionScript) must be ECMAScript-compliant.
The guidelines now emphasise functionality over identical layout across browsers (paragraph 39):
You should check that the content, functionality and display all work as intended. There may be minor differences in the way that the website is displayed. The intent is not that it should be pixel perfect across browsers, but that a user of a particular browser does not notice anything appears wrong.
Graceful degradation without scripting/ plug-ins and accessibility are required (paragraphs 41-42)
You should also test your website to make sure that it works with scripting and plug-ins turned off.
Some users will be unable to use pointing devices so you should verify that the site works using a keyboard only.
I could be churlish and quibble about a couple of points in the document that I personally disagree with, but I won’t; the philosophical framework of the new Guidelines is a scalable, future-proof one that will properly serve taxpayers, web visitors and government webmasters in the UK.
I’d like to congratulate Adam Bailin and the team who revised the guidelines, and I’d like to congratulate every one of the 400+ readers who took the time and the trouble to write and support web standards.
It’s a job well done.
(Disclosure: I work for Opera, the browser vendor, and wrote the Opera consultation response).
]]>I think this tweet by caledoniaman sums up the level of anticipation:
WCAG 2.0 and a new Guns ‘n’ Roses album in the same year. What’s the world coming to.
Interesting comparison. They’ve each had about as many pre-releases. In any case, I can say, having spent over 8 years with it, that WCAG 2 is not as entertaining as Chinese Democracy. But I do think that it’s better equipped to stand the test of time.
If I had to pick one thing I’m most happy about, I’d say it’s that the HTML- and text-centrism in WCAG 1 is largely gone. In its place is a much more flexible (dare I say robust?) concept of accessibility-supported technology. So when newer technologies can show themselves to be directly accessible, they too can be used in WCAG 2-conformant content.
Over the years, many people have conflated “WCAG-conformant” with “accessible,” and that’s led to people making statements like: “Don’t use JavaScript–it’s inaccessible.” That’s bad for everyone, from users with disabilities who actually can work with JavaScript (which is to say, the vast majority), to Web designers and developers, to policymakers, to those developing new technologies.
With WCAG 2, “Don’t use x” is no longer valid. (Was it ever?) It is now up to you, the developer, to work on the direct accessibility of your content, no matter what technology you choose. I believe we’re about to experience a new wave of accessible design techniques, as a result.
But first, we need to flush “Don’t use x” out of our system. Some are accustomed to saying it about anything they’re not comfortable with. That’s only holding accessible design back. It’s time to learn what’s out there, today, and use it in everyday Web design. It’s time to make everyone’s Web more accessible. Have a look at the WCAG 2.0 Recommendation, and its supporting material. Then, start thinking about what a more accessible Web could be. We still have a lot of work to do.
]]>The article is now available in both Spanish and French.
Interested in translating it? Then contact Gez, he’d be happy to hear from you.
]]>