Geek in the Park: Pragmatic accessibility

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 sup amd sub be nuked on the grounds that they are purely presentational, and he suggests that the yawnishly nerdy samp, samp, 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!].

Patrick’s bit

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 “Fuck ‘em!”.

Maoist self-confession

Pat talked real-world. On, 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.

8 Responses to “ Geek in the Park: Pragmatic accessibility ”

Comment by bruce

Mind you, unlike the author, I’d retain dfn as well. Look at Gez Lemon put the long-overlooked dfn tag through its paces.

When Hollywood finally makes Web Standards: the Teen Movie, dfn will be the girl at school with mousey hair, glasses and tooth braces. The captain of the basketball team, Gez, asks her to go to Prom in order to humiliate her, and she turns up with her hair done, contact lenses in and all made up, looking absolutely gorgeous, and they fall in love and fly up to the moon in a Pontiac Firebird like at the end of Grease.

Sob. I’m filling up. It’s so romantic.

Comment by dotjay

I’ve long-wondered why browsers generally fail to ask users a few questions about how they want their software set up. So many improvements, so little… time? money? motivation?

Sad to have missed Geek in the Park, but just wasn’t possible for me to get there. Nice work gentlemen. Looking forward to the “inadequacies of user agents” – I have a draft bloggage on that from December that never got posted… :(

Comment by Rob Kirton

I found the bit about the text resize plugin to be of most interest. Prior to release 1.5 firefox, I contacted the lead developer and suggested that a sure fire winning feature should be a simple two standard buttons on the menu bar. The opera zoom everything method would possibly be most appropriate. I was given a (polite) brush off and told that better solutions were on the roadmap. Maybe so.

I realise that the current tool bar only navigates, and this changes this. I would howver argue that the function is as equally important as those already there, especially if a user is suddenly thrown ionto a site where no thought has been given to the real effect of using small font sizes as default. Surely it could be accomodated somewhere?

It is unlikley that the average user is likley to download and install a plug in.

What annoys me is that browser manufacturers have repeatedly made it so difficult for the novice / average guy in the street user to perform what is a very essentiial task for many of them. Having in the past taught an number of novice / elderley Internet users, I am sure that such a standard text resize feature would have been a great boon. Getting them to remember where to got to to find the existing feature, was always difficult. Short cut keys helped, though again we techies should rember that average users are not necessarily inclined to rememebr a number of short keys / functions

All I can say is keep writing and plugging away about practical real life issues of usability / accessibility.

PS dont get me on about why browsers are so right handed. Why not a feature for allowing the scroll bar to be set to the left side. Not only would it probably help the 10% or so of users (50% of my offspring) who are left handed, it may even help with sites where the navigation is on the left, helping minimise mouse movements.