WebAIM (Web Accessibility in Mind) have released their second Screen Reader User Survey to help Web Professionals learn more about how to design for universal access.
It’s well worth keeping an eye on as it asks questions on how to write alt text to images that convey mood, questions about ARIA, Flash and the accessibility of some high-profile sites.
I was invited by some nice people at Vodafone to come along to the launch of Vodafone 360.
Amongst all the glitz and glam PR ladies that made me feel like I’d walked into a Bond film was a real product: a couple of new Samsung phones and a raft of applications and services provided by Vodafone. I’m not their marketing department, so you can read all about it on the 360 site.
After watching a sexy video about Nick (a “typical 360 customer”) who seemed to do nothing else other than take black cabs around the West End to hang out with glamourous 20 year olds, only one of whom ever did any work (and that was restricted to nodding her head and languidly sliding up a fader on a mixing desk), we looked at the tech.
The 360 services are applications pre-supplied by Vodafone. There was a live-demo (brave!) of an application made by Domino’s Pizza that allows the user to buy a pizza incredibly easily; the phone’s GPS told the nearest shop the user’s location, and the cost of the pizza is added to the user’s VF phone bill.
What’s interesting thing about the 360 applications is that they’re not built using Java, C++ or some vendor-specific language. Instead, they’re written using HTML, CSS, JavaScript and packaged up according to (draft) W3C spec called Widgets 1.0: Packaging and Configuration. The packaging is as simple as writing a config.xml file or using the Widget Packager wizard to do it for you, and zipping up your config, HTML, CSS, JavaScript and any images and renaming the resulting file with a .wgt extension. (Widget tutorial: Making a mobile Twitter client.)
For Widgets, read “applications”; I think the name does the spec and concept a disservice, as it implies trivilality or toys. What’s cool is the Vodafone implementation has “live” icons that can display info even when the application isn’t fully opened.
The advantage to using W3C widgets (and presumably the reason that Mr Vodafone invited me) is that if you know how to write standards-compliant web pages, you know how to make mobile phone applications. Vodafone are encouraging developers to write and sell through their app store which operates a 70/30 revenue split, favouring the developer. (There will be a €1million prize fund for the best new widgets, they said.)
The emphasis on standards continued in a surprising way; a venture capitalist lady on a Q&A panel talked of W3C standards being advantageous to both developer and customer. There was a VF suit with a whole slide listing standards and a W3C logo. This was all music to my ears, of course, given that I’ve been banging on about the benefits of standards for years, but it was odd to see so many suits repeating it.
The success of 360 remains to be seen; I think it’s launched to consumers in a month or so. Its DRM-free music is a plus, but the quality of the handsets will be the Christmas make-or-break, in my opinion. I’m no fan of the iPhone, but for user experience it’s without equal so the new Samsung hardware will need to be pretty special in a way that my Samsung Omnia isn’t.
The day was surprising in that I met three people I didn’t expect to see; the first was Opera’s CEO Jon von Tetzchner (=my boss) who was speaking on the expert panel as Opera is the 360 browser.
The second was ever-cheerful Cathy Ma who introduced me to people with an anecdote about nipples, and the Mobile Web Best Practices Working Group‘s answer to John Steed, Jo Rabin, who I’ve spoken to every Tuesday afternoon for many months but had never met.
And so to the party, where much beer was consumed and CSS Media Queries discussed.
Last night, I got a few angry emails after I wrote on Twitter that some visiting relatives were “Bible-Bashers”. I’m happy to accept I’m wrong; they are “God-Botherers” who enjoy going to church but otherwise don’t mention it to people who don’t share their views. There’s a difference.
“Bible-bashers” are those who feel the need to spread their views to others. It’s a term that comes from the religious pamphlets of the English Civil War of the seventeenth century, describing aggressively religious people.
To find out which you are, take this handy quiz:
Do you believe you have an Invisible Friend In The Sky? (Yes=1 point, No= 0)
After spending a few days creating the billions of stars in the billions of galaxies that fill the awe-inspiring majesty of the universe, does your Invisible Friend In The Sky now spend its time closely monitoring your daily actions and reading your thoughts? (Yes=2 point, No= 0)
Does your Invisible Friend In The Sky care which adults you have consensual sexual intercourse with? (Yes=5 points, No= 0)
Is your Invisible Friend In The Sky eternal, beyond the laws of causality and entropy and undetectable by science? (Yes=1 point, No= 0)
Does your Invisible Friend In The Sky regularly intercede in the material world on your behalf (good grades, safe journeys, speedy recoveries) because you ask it to? (Yes=1 point, No= 0)
Does your Invisible Friend In The Sky routinely neglect to help blameless people caught up in calamities like genocide, war, famine, earthquakes or tsunamis because it “works in mysterious ways” (or other manifestations of inscrutability)? (Yes=5 points, No= 0)
Does your Invisible Friend In The Sky require subordinate behaviour from women such as covering their hair, wearing shapeless garments, not being allowed to teach in places of worship or hacking off each others’ external genitalia at puberty? (Yes=10 points, No= 0)
Does your Invisible Friend In The Sky require you to tell people with a different Invisible Friend In The Sky (or no Invisible Friend In The Sky) that they are wrong? (Yes=10 points, No= 0)
Does your Invisible Friend In The Sky think it legitimate or laudable to kill people with a different Invisible Friend In The Sky? (Yes=20 points, No=0)
Are you angered/ offended by this quiz? (Yes=5 points, No=0)
If you scored zero, you are not a God-Botherer.
Between one and five, you might be but don’t know it; you probably tell people that you’re “a spiritual person”.
Between five and ten, you’re a God-Botherer.
More than 10 makes you a Bible-Basher. 20 or more and you’re a fundie.
When Henny and I dreamed up the standards.next format, we were privileged: we work for Opera, which really supports standards so we get allocated time to work on these day-long geekfests without having to aggressively pimp the company or worry about turning a profit.
However, when we decided to run what I think was the first ever event dedicated solely to cognition and accessibility, I expected only a dozen people or so to show up.
Wow! Over forty came, including one lady who flew from Madrid specially (thank you, Emmanuelle!)
I knew it would be a great day when, hopelessly lost at Angel tube, I asked a guy on a “no ID cards” stand for directions to City Uni. “Are you going to standards.next?” he asked me, promising to show up 30 mins later (and he did).
I shan’t repeat what each of our excellent speakers said, as their slides and videos are available on their sites:
In Ian Pouncey‘s talk, Ian mentioned that people with cognitive needs (including older people, people new to the Web) need consistency of look and feel with controls. Don’t style form buttons, he suggested.
This resonated with me as lately I’ve been thinking a lot about the new features HTML 5 brings to forms. When I demo them, I’m always always asked if they can be styled. At the moment, they can only be styled up to a point: for super-specific styles to new sliders, calendar widgets, we’ll probably need new pseudo-elements from CSS Working Group, perhaps in the Basic User Interface module.
Ian’s comment led me to wonder should they be stylable at all, a question I asked of the meeting.
1) If you don’t allow it, people will do it anyway. If HTML 5 does not support this we will have to create our own bastardised JavaScript replacements, which will be inaccessible, unusable, and unrecognisable by anything querying the DOM as what they actually represent.
2) Although we know they ought to and recommend that developers use the default OS styling, to take away the option is too strict. We are pushing standards, not limits.
3) Allowing developers and designers more flexibility allows them to come up with new more intuitive and surprising interfaces and uses for these elements that we would never have thought of.
4) It’s what the customer wants. And what they want, essentially, they get. The biggest complaint about the “select” tag is that we cannot style it. This led to on my very first day at BSkyB me blogging this www.zeroedandnoughted.com/?p=14 because of this: http://tv.sky.com/tvlistings
The dropdowns had to match the branding. There was no option otherwise. Because I could not “colour it in” we had to make our own bespoke dropdowns. Immediately, failures were made to recreate the OS’ behaviour. The selected content of the dropdown did not match what was displayed. No keyboard access. JavaScript only. If we had been able to style the dropdown then we would have been able to achieve all of this, and in far less time. Without being able to, yes, we were pushed along the path of using the OS default. Was that the chosen option? No. We ended up with a pretty (subjectively) but inaccessible solution, with no decent business case to improve upon it.
5) If we do not allow this, developers/designers will use the next available attribute that will let us do this with the least pain. Submit buttons become anchors, for example, and then we have dependencies on JavaScript, and the entire web become less accessible and less semantic.
I would love to know your views on the stylability of forms.
Jamie Knight’s screenreader and HTML5
Something else that made me think of HTML5 (because I’m heavily focussing on accessibility there) is Jamie Knight’s discussion of his screenreader use. He’s not blind, but sometimes finds it easier to listen to a page than read it. He made his own screenreader that listens out for certain ids or class names like “navigation”, “menu”, “sidebar” so that his screenreader can skip the peripheral information on repeated views.
With the “baked-in” elements like nav, footer etc, this would be achievable with much greater precision.
What did the day achieve?
Personally, the after-conference chats are as important to me as the “official” talks. I was delighted that conversation and debate continued into the night, with people who hadn’t met each other swapping ideas, insights and business cards. That’s one of the results I’d hoped for: connecting people who might have been working in isolation.
I also met one of the accessibility good guys, Matt May from Adobe. I’ve known him for ages on-line; most recently he’s been helping Lachlan Hunt and I understand the kind of things that will be needed to make canvas accessible—the kind of things that got added to Flash in version 5 to retrofit it for accessibility.
I was clutching my battered copy of the excellent book Universal Design for Web Applications that he wrote with Wendy Chisholm so he could sign it for me:
So, in conclusion: thank you to all our speakers and all who attended. I wholeheartedly agree with a tweet from isolani:
Today reminded me again what a marvelous accessibility community we have within the UK.
Of course, we know that in the real world, most people do not have an
iPhone and don’t use a Mac. This is a demonstration of the potentially dangerous belief that “my customers
are the same as me”. As everyone wants to make their sites mobile-friendly, and as today sees
the release of Opera Mini 5 beta, now is a good time to explain what
Opera Mini is and how you design for it and test it.
What is Opera Mini?
Web browsers are hugely complex beasts. Working out the interaction
between HTML, CSS, SVG, JavaScript
and rendering it all is highly processor-intensive. They rely heavily on
Operating Systems (which is why making cross-OS browsers like
Opera and Firefox is hard).
World-wide there are 100 million or so smartphones, each of which has an
Operating System that can run a full web browser such as Opera Mobile or
Safari.
But there is an estimated 1 billion lower-specced phones around the globe, many of them in the
developing world (but by no means exclusively so; how many people do you know with featurephones rather than smartphones? A lot, I’ll bet).
Because it’s a world-wide web, and not just a wealthy Western web, we
developed Opera Mini, which works on all phones—even on the lower-end ones, as long as they support Java.
There often isn’t enough processing power to render the page on these phones, so the
requests are pre-rendered on servers running Opera’s layout engine and the result is sent
to the phones from the server as a heavily compressed “snapshot” of the
page. It’s by no means uncommon for this to be as small as 10% of the size
of the original page.
Because of this heavy compression, displaying pages on the user’s device occurs much faster than if it had processed the page itself, and for those who
pay by the amount of data downloaded it’s also a huge cost saving. This
compression and data saving also explains why many Western users of smartphones
use Opera Mini to reduce bankruptcy-inducing data-roaming charges when
they travel to a neighbouring country.
How to ensure your site works in Opera Mini
The same way that you ensure your site works in every other browser: design
using Web Standards and make sure
your code validates.
Don’t be immediately tempted to start building a special mobile-only verson of your site (see my ZDNet article Forget the mobile web: One site should work for all). Using CSS Media Queries, you can send reformatted screen layouts to devices according to their display properties.
Leverage those accessibility synergies!
Another secret of developing with mobile devices in mind is to consider
accessibility. If you think about it, having a small screen with no
keyboard is somewhat like browsing with
assistive technologies.
Many people on expensive data plans browse with images turned off, so
sensible alternate text gets the content to them. Many older mobile
devices have limited fonts and colours, so by not using those as the
sole way of giving information makes your sites both accessible and
available to mobile devices.
One of the cool things in HTML5 is intelligent forms, which are implemented most thoroughly in Opera (so try them there) and which are apparently “coming soon” in Google Chrome.
In legacy browsers, the intelligent forms just fall back to text input fields.
Safari displays input type="range" as a slider, and also the once-proprietary, now standardised placeholder attribute. Watch what happens in Safari when you click in and out of the email field.
And don’t forget to view source for that “Look, no JavaScript!” moment.
You’ll need Firefox 3.5 for these (I was demoing using an Opera Labs build, but it’s not publicly available yet).
Remember – there are no browser plugins running here, so the video element is completely available for manipulating with script. That’s the killer feature.
Video element demos to show how you can script your own controls, and interaction with SVG
The hour-long workshop “How to build a HTML5 Web site” involved me coding in real time (with hilarious typo consequences like “Dictype” instead of “doctype”; frankly, I’d be better typing with my dic than my hands).
the author’s version of the HTML5 specification (much shorter than the main version, which has lots of information for browser makers, but which is generated from the same source and therefore up-to-date)
There will be a video available, and the Carson types have promised that they’ll publish a transcript simultaneously. It’s nice to see them taking accessibility seriously, and I was pleased to see that they had someone signing the sessions for hearing-impaired.
You can grab the slides and notes for my second session, The Future of HTML5, which I tweaked slightly to deliver on Monday in Glasgow.)
OK, so it’s not quite a millenium but the flame wars, bitch fests on the mailing list make it feel that way.
Microdata/ RDFa
According to the W3C‘s RDFa primer, it is “a few simple XHTML attributes … [to] mark up human-readable data with machine-readable indicators for browsers and other programs to interpret. A web page can include markup for items as simple as the title of an article, or as complex as a user’s complete social network.”
HTML 5 had the temerity not to care about the RDFa for three reasons (as far as I can tell):
It requires XML namespaces and HTML 5 doesn’t do namespaces
If you copy and paste RDFa annotations, it won’t work in the destination page unless you also copy the RDFa definitions, which can be separated in the code.
So instead, HTML 5 introduces microdata which does the same thing in a different way. To some, this has caused grave anguish. Shelley Powers is anguished because it competes with RDFa, Ian Hickson wrote it on his own, the HTML 5 spec is too big already and microdata isn’t as “good” as RDFa.
Anyway, this crazy mindset of Philip’s in which things are tested and the best one wins regardless of ideology seems to have infected others. Ian Hickson writes
I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand.
As someone only tangentally concerned with machine-parsable data (I’ve used one microformat in my life, once) I’d love to see the three options compared by someone like Tantek, Jeremy Keith or Ben Ward. (Wish granted in Ben’s comment.)
Accessibility
Summary lovin’ had me a-blast
The decision to deprecate the summary attribute of table caused what we lucky denizens of W3C Working Groups officially term a right shitstorm.
From a barely-used accessibility add-on, it became a talisman whereby the mature accessibility experts with real experience beat up the juvenile upstarts who are all clever ideas and no practical knowledge, while the brave young pioneers with the courage to boldly forge new paths attacked the silly old farts who are afraid of change.
It’s settled down now, with summary remaining in the spec but advised against (a sensible compromise, in my opinion; I think summary is superfluous).
A highly condensed partisan history of Oh, those summary nights is available from Google’s Mark Pilgrim, who memorably did his bit for inter-generational bonding by calling some accessibility practioners “charlatans and fools”.
ARIA integration
This is vital work. ARIA is a bolt-on spec that extends HTML 4 to cover the accessibility of Web Applications, which stretch HTML 4 to breaking point because it was designed for static documents, not apps.
That stretch is one reason that HTML 5 was invented; its original name was “Web Applications 1.0”. Because HTML 5 is a new spec, it’s better to have accessibility built-in rather than bolted-on.
Also, the ARIA spec is complex and puts a lot of work on the developer, so it’s in everyone’s interests that ARIA be folded into HTML 5’s existing structures as far as possible.
Fortunately (and surprisingly, given the summary fracas) no-one seems to be disagreeing on the need for the HTML 5/ ARIA integration process which appears to be going smoothly and without horses’ heads being left in beds.
canvas accessibility
canvas is the immediate drawing mode available in HTML 5. It’s fast, and therefore sexy, because it doesn’t have a “DOM”, but which means there is nothing for assistive technologies to hook into.
Some have suggested that canvas be removed from the main spec, but that would make little difference except to confuse authors who already have too many specs to cross-reference.
Because the spec retrospectively codified what was already working in the browsers, we just have to accept that those implementations are inaccessible for now and not use canvas where a more accessible method exists.
However, the first part step towards solving a problem is acknowledging that there is a problem, and it’s acknowledged that the original use-cases anticipated for canvas don’t match what people are trying to do now (further discussion of this in my standards suck video interview).
I know that cabal member and fellow Operative Lachlan Hunt has been investigating how my old chum Bob Regan of Adobe went about retrofitting Flash for accessibility, way back in version 5. That’s a promising sign.
New chairs
Chris Wilson of Microsoft resigned as co-chair, and two people replace him: Maciej Stachowiak of Apple, a cabal member through and through, and Paul Cotton of Microsoft. I don’t know Paul, but it’s good to see Microsoft continuing its involvement, and certainly we’re seeing lots of specific feedback from Internet Explorer Program Manager Adrian Bateman.
Super Friends
Zeldman and a group of celebs including Eric Meyer, Tantek Çelik, Dan Cederholm adopted the moniker HTML5 Super Friends and endorsed the direction the spec’s going, thereby immediately making it primetime.
I agree that hgroup is clumsy and likely to be misused. Rather than wrap an h1 and its h2 subtitle in hgroup to keep the subtitle out of the outlining algorithm, I would prefer to use
<header>
<h1>My blog</h1>
<subtitle>My wit and wisdom</subtitle>
</header>
as I think that’s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.
The footer content model
I agree that it’s daft that you can have nav, headings and sections in a header but not a footer, and this contradicts what many people already do—see Webcamp BKK for an example taken at random from HTML5gallery.com.
Contexts in which this element may be used: Flow content, but with no header or footer element descendants.
The dialog element
I’ve said before that
That better option is no longer available in HTML 5 which unnecessarily restricts the cite element to only marking up the title of a work (in HTML 4 you can use it to mark up a name).
In my opinion, the HTML 5 spec is overly restrictive, as I’d like to continue using the blockquote/cite pattern, as dialog has no mechanism for marking up stage directions such as “Exit, pursued by a bear“.
Frankly, I’m not even certain that dialog merits its own element. If no-one is convinced that marking up ancient or fuzzy dates has a use-case, what is the use case for dialog? Adrian Bateman of Microsoft agrees with me:
We also don’t think dialog adds sufficient value to justify the spec,implementation, and test cost.
Learn more
If you’re looking to read the HTML 5 spec from a markup author’s perspective (that is, ignoring all the stuff for implementors), you can find the huge single-page Author spec and multipage Author version.
There’s a 10 min video interview on Standards Suck talking about some of the issues above, and an interview with Government Computer News in which I talk about HTML 5 development and its relationship to the US accessibility standards section 508.
Opera 10 marks a new time for our browser, with its sexy new UI, cherry-red restyled “O” logo, standards support including many advanced features not found elsewhere, and improved developer tools. Not only that, but to coin a silly Carpenter’s song…”we’ve only just begun.”
Opera has always had a reputation of being a browser for the “power user” as it’s so customisable, but that can often be off-putting for non-geeky customers (I’m thinking of my Dad here).
So Opera 10 adds spell-checking and auto-updates, as well as a much sleeker user interface in which you can move the tabs where you want them by hovering over the tabs, right clicking and choosing “Tab bar placement” (see my 45 second amateur YouTube tutorial).
Speed dial is now easily customisable (before you had to edit a config file—never much fun for a user) and you can add a background image too.
These make all the pre-existing features (sessions, mouse gestures, excellent keyboard support) all the more usable to the mass market.
One feature outshines all the others, though, for people using Opera 10 desktop outside of the industrialised world (or in crowded WiFi hotspots), and that is Opera Turbo. This speeds up browsing dramatically over slow connections, by compressing images —on the assumption that mostly you want to read the content rather than look at the pictures; if picture quality is important, you just turn Turbo off. (This works on slow connections, when compressing the images is faster than sending them down a slow line. On broadband, it’s faster to send them down the line than it is to compress them on a proxy.)
I’m proud to see this release, which strives to bring an excellent browsing experience to all, regardless of geography or infrastructure.
But enough seriousness. Check out this fun video about Norwegians’ love for compression and flat-packing:
