Yay for the Geek in the Park meeting. I missed the picnic, as I was returning from monstrous partying for my kid brother’s birthday, but got there in time to actually have a pre-speaking run-through with my partner-in-crime, Pat Lauke, to make sure the two-handed presentation we’d jammed by phone and mail worked.
It was splendid to meet old mates like Matt Machell, the excellent Jim O’Donnell, as well as meet more people (and a shame I couldn’t meet others – who were these people, for example?)
My notes, combined with some notes Patrick gave me, are reproduced. These are dense, as we talked for two hours, as this is just our crib sheet rather than a full transcript (if you want the full thing, we are available for weddings, barmitzvahs and satanic orgies. Especially satantic orgies).
Pragmatic accessibility – where the rubber meets the road
Accesssibility is starting to get acceptance from the big corporations – that’s A Good Thing. But it means compromises. Whereas on a blog, you can tweak the design for accessibility, you often can’t on an commercial, enterprise site. People who say “It wasn’t perfectly accessible,so I changed the design” are generally incredibly powerful in their organisation, working for a company that specifically sells to disabled people, or working on one-man-bands.
Most of us work with branding; marketing; content management systems – accessibility has to make compromises. As Molly wrote
Internal web standards evangelists have it the hardest … You work in business, education, government or some other organization. You climb the corporate ladders, battle the academic arrogance, stave off the government paperwork and endure the organizational politics.
That doesn’t mean give up on the good fight; many of us already implement accessibility “under the radar”; valid code; labels and forms; alt text; structured code (headings etc) can generally be implemented without other stakeholders moaning. So it’s demanded that some document be a PDF? Mark it up properly and it can be reasonably accessible. Not as good as html, but better than nothing; a happy medium can be achieved.
Other things are not so easy to do: skip links takes up valuable screen space in the area usually reserved for branding etc. Unique link text (instead of “more”, “more”). Text instead of images of text. Liquid page design usually offends marketing (and, arguably, may be less accessible, as it could lead to gigantically long unreadable lines).
Fixed width isn’t inherently itself inaccessible but can lead to broken layouts when text size expands. How many text-size increases should a site accommodate? I reckon at two or more as a minimum; Robin Christopherson (a blind developer at abilitynet recommends five).
If the user really needs more (500%?), then they may be better served with a modern browser that resizes entire display (zoom in opera and IE7)?
Can’t get true semantics with html, anyway
Bit of a tangent when I expound on my arguments that html is a flawed language, and we talk through some of Patrick’s fisticuffs on the xhtml 2 lists where he argues that
sub be nuked on the grounds that they are purely presentational, and he suggests that the yawnishly nerdy
var are much too specific for xhtml, which is supposed to be a generic markup language:
XHTML 2 is a general-purpose markup language designed for representing documents for a wide range of purposes across the World Wide Web. To this end it does not attempt to be all things to all people, supplying every possible markup idiom, but to supply a generally useful set of elements. (Source)
Accessibility isn’t just our problem
We’ve both said publicly that accessibility is the reponsibility of the user, too. They need to come with decent kit.
But lately we’ve both been documenting the inadequacies of user agents (to publish in the next few weeks). Hopefully on WaSP site (if we can get philosophical agreement of whole ATF).
The browser manufacturers pay lip service to UAAG but they only satisfy the letter, not the spirit [if that!].
- Why should we need “skiplinks”? Can’t the UA do that?
- IE7 still has the broken in-page links problem
- What possible justification can the browser manufacturers give for the value of the
titleattribute only to be shown on hover?
- Users constantly cite inability to change font size as a problem – not just people who self-define as “disabled”. Problem is, they could do it, but the options are so buried in menus. Shouldn’t it be default on the toolbar?
This is very cut-down, as I don’t have as many notes of Pat’s talk, so I can’t remember exactly when he shouted
Pat talked real-world. On www.salford.ac.uk, he uses a fixed-width page (as it was too exotic i mark-up + css terms to get semi-liquid layout reliable across all browsers). He has buttons that are images of text (the beast!), uses images in the markup when they could/ should be background images in the css.
Pat also noted the real-world enterprise-level concern of handing over sites to less than skilled authors: yes, I could use very refined trickery (image replacement, sifr, clever use of transparent gifs, expunge all non-content images and use css backgrounds, use ID on body and long CSS rules to highlight current section in navigation), but the reality is that they’d never understand of use them properly.
If an author wants to put a few images in a page to accompany a few paragraphs, can I realistically expect them to add an ID to each para and create CSS to load the decorative images as a background, leaving enough padding, and possibly a min-height? of course not. Why should they? They’re subject-matter experts, not Web geeks.
We’re doing the WCAG, You do the UAAG!
The onus is on browser/OS manufacturers to make options more obvious. text-size buttons (see my Firefox text-size toolbar, still my simplest yet most popular creation) should be shown by default in IE/FF/etc.
What about a simple dialog on install/first run: “set up your browsing environment”, wizard guides you through your options (“do you want big font sizes? text size buttons and print buttons right there? do you need special colour combinations, overriding the ones defined by designers? should i linearise all your pages by default?” etc).
Same goes for OS (“do you want high res or low res? large font sizes? high dpi?” etc). why do we as web CONTENT developers have to make up for problems in UAs?
Again, pragmatist says we need to (somebody think of the users!), but it stinks that, of the various guidelines, WCAG is the one so strongly burdened while UAAG is ignored for the most part.
Tools in a bar. That makes a toolbar!
What about a toolbar that is written for consumers which patches the shoddiness of the UAs? Good natter with Andy Higgs here; Andy’s written his thoughts up.