Standards.Next: cognition and accessibility

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:

Here are some write-ups of the day:

On the styling of form fields

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.

Antony Kennedy told me that they should:

Because:

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:

Mr Blorsensen: thank you for your support. Sorry, no refunds

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.

(A few more photos)

16 Responses to “ Standards.Next: cognition and accessibility ”

Comment by Thoughts around universal access on mobile from Accessibility 2.0 » iheni :: making the web worldwide

[...] This reminded me of the work Dean Edwards (Brothercake) presented and Standards.Next on HTML5 where he showed HTML5 forms could be stylable if browsers inherited the user’s settings from the OS. Styleable forms for HTML5 is something that we are asked about a lot at Opera and seems to have sparked a lot of opinion. If you have any ideas or suggestions then head over to Bruce Lawson’s blog and let him know what you think. [...]

Comment by Ben Millard

Well said on the subject of form controls. I’m surprised companies who make web products are spending millions on ARIA. The real solution is clearly improving HTML’s controls and making them styleable through CSS. That’s where the money and talent should be going, IMHO.

Native controls are natively accessible. Styling them with CSS is consistent with styling anything else in HTML.

Different types of control are already selectable via the name of the element or, in the case of <input>, via the value of their type attribute.

XBL also seems unnecessary when the parts of each control could be selected using pseudo-elements. Control states are already selectable via their attributes (such as whether checked or value are not the empty string). Further states are selectable using existing pseudo-classes (such as :active and :focus).

The extremely limited set of selectors in IE6 is one of things which makes selecting form controls so painful at the moment. You basically have to add a class to each and every one since attribute selectors aren’t supported.

Accessible controls will usually have an id for use with <label for>. But selecting via this this requires the CSS to be totally bespoke, with long chains of selectors on sites with numerous forms. It also means each new form needs changes to the site’s CSS and you just have to hope each user’s browser updates their cache.

As for the new sectioning elements in HTML5, authors I’ve seen are always confused by them. It seems inevitable they will become so widely misused that their semantics will be no more certain than <div id="content">. And with the new document outline algorithm and the push for yet another niche feature being added to CSS, heading structure and styling will become more confusing than ever.

Incidentally, I notice your numbered list isn’t using <ol> and your URLs aren’t clickable. They should probably have proper link text, rather than the URL. (I can see the URL in the statusbar or tooltip, depending on browser.)

Comment by Bruce

Incidentally, I notice your numbered list isn’t using ol and your URLs aren’t clickable. They should probably have proper link text, rather than the URL. (I can see the URL in the statusbar or tooltip, depending on browser.)

Ben, I’m quoting Antony Kennedy. To make “proper link text” would be to misquote him. What would be the point of marking up his numbered list?

Comment by Mike Taylor

Most of the new HTML5 forms can be styled, at least in the most basic ways using attribute selectors. For example, I can style all inputs with the boolean attribute ‘required’ with the following:

[required] {border:1px solid red;}

Also, the date form elements font can be style, for example:

[type=date] {font: normal 15px ‘Hobo Std';}

It’s not entirely cross-browser, but for now it’s something to work with. In my opinion, the real problem is the lack of styling hooks for the time widget within the datetime type, for example.

You can see some of my css experiments over here: http://miketaylr.com/pres/html5/forms2.html

Comment by Alberto Calvo

Form fields are the worst cross-browser styling nightmare ever made. And they shouldn’t IMO. The only concern I see is about accessibility on that is to teach people how to style them properly, just like any other element on the web. Default styling could be a lot improved for usability and accesibility with CSS, not just for making it pretty.

I suscribe all of the Anthony Kennedy’s points word by word. Seriously, if any improvement on that is possible, it would be really appreciated by the community: designers, developers and (I’m pretty sure) users.

Comment by Steve Workman

I completely agree, every aspect of HTML should be able to be styled. Imagine a brand web site where oddly-styled pop-ups started appearing, the marketing/brand manager would have a fit!

The real question is how, how can we use CSS to style native form elements.

Making an assumption that the native form assistants are made using HTML, they need to be standardised and selectable i.e. input["date"] > calendar { background:blue; }. I’m very open to ideas as to how to do it but I can’t see much else. I’m still wondering how I’d style the tag to make it look like those in the HTML 5 doctor’s post http://html5doctor.com/measure-up-with-the-meter-tag/ – very open to non-DOM manipulation methods here too.

Comment by Ben Millard

Bruce, what was the original source for that quote? The cite attribute is absent from the <blockquote> and the preceding paragraph only points to the homepage of the author.

I tried some searches using that website’s search box but couldn’t find a page with the content you have quoted. For example, there were no results from a search for “BSkyB”.

As for whether an ordered list should use <ol>, well, I thought semantic markup was a good thing? :P

If you are quoting from speech rather than from a written source, conveying the structure of that speech using markup is appropriate. Especially since text loses the manner and timing with which it was said. (The absence of speechmarks mean I’m not sure speech was the source, either.)

Adjusting poor form when quoting material is also a valid thing to do, so long as the edits are marked. This includes correcting typos, removing invalid or presentational markup, changing the visual style and replacing URLs-as-link-text with proper link text. All come under the editorial prerogative of a site owner who chooses to quote from another source, AFAICT.

Such edits do not change the meaning. On the contrary: they make the meaning more apparent.

Did you have any thoughts about the main body of my comment?

Comment by bruce

Ben, the source is an email.

I can’t see what the main point of your comment was; if it was to tell me that you disagree with my markup choices, then: noted.

I agree with you that “Native controls are natively accessible. Styling them with CSS is consistent with styling anything else in HTML.”

Unfortunately, I see nothing in CSS that allows me to style calendar widgets for input type="date" so I could (for example) style weekends in red and weekdays in black, or change the way the pointer looks on input type="range".

Until these can be styled by designers, they will use the jQuery-like UI libraries that allow such styling as they “fake” the form controls. This means potentially less accessibility, more code and slower uptake of the native form controls.

If it were up to me, I would like the browser manufacturers to get together to agree a temporary measure for solving designers’ natural wish to style. Perhaps something like vendor specific CSS but instead of a vendor prefix, something like -html5-slider-pointer that could be given a background image, colours etc.

Comment by Alberto Calvo

Another stuff that I want to aboard is the ugly default style for HTML5 forms on Opera, which I really hope they can be changed in the future. Using colors and complicate metaphors are bad ideas. What about using a set of default SVG glyphs that change its color depending of the input’s color property? Of course, that SVG glyphs, should be able to change to via CSS :)

In example, you could check http://www.culinaryculture.com/ . Don’t check the source, but the glyphs. IMO, they’re pretty much well integrated with every page design. They’re neutral with the design and very meaningful to the user.

Comment by Ben Millard

Unfortunately, I see nothing in CSS that allows me to style calendar widgets for input type=”date” so I could (for example) style weekends in red and weekdays in black, or change the way the pointer looks on input type=”range”.

Indeed. That’s why I think the money should be going on the long-term CSS solutions to these things, instead of band-aid-to-HTML solutions like WAI-ARIA.

“Do it once, do it right.”

Comment by bruce

Ben – in the real world of commercial web development, people won’t use any of the new form input types if they look ugly and can’t be styled to fit the rest of the page.

jQuery UI http://jqueryui.com/ has some great-looking widgets faked in JavaScript; no incentive for devs to move from that.