One congratulates the Web Standards Project on the inauguration of the Accessibility Task Force (ATF). Its formation was a complete surprise to me. But if I read the tea leaves correctly, it was broadly implied that I could join, but I responded honestly that the WaSP needs someone less scorched-earth. Plus I already have enough to procrastinate doing. (And where are those promised macaroons reading JOE SAYS: YOU’RE A WANKER!?)
WaSP’s task is actually going to be just as hard as persuading browser- and authoring-tool-makers to accept and generate compliant markup. The fact that many adaptive-technology vendors are mom-’n’-pop operations is actually a hindrance, since they are so busy and wedded to Microsoft, Microsoft Internet Explorer, Microsoft Windows, and Microsoft Active Accessibility that they don’t know the first thing about Web standards. Then there’s dealing with colossi like Apple and indeed Microsoft. (Adobe I wouldn’t worry about, based on my insider knowledge. You heard it here first.)
Now: Wishlist? Did somebody say wishlist?
Find a way to communicate with Freedom Scientific (makers of Jaws) that doesn’t involve shouting. The only way I got them to take me seriously a couple of years ago was to endure a 45-minute hazing ritual disguised as a telephone call, in which a vice-president did nothing but yell at me (I refer to a voice raised in anger). He ignored my arse completely in that call until I started yelling back. Curiously, for a year after that he pleasantly and helpfully responded to E-mail.
Yet Jaws still performs poorly with standard markup. I guess they figure that, with 80,000 users and a gold-plated revenue stream, they can afford to be arrogant dicks. They ought to grow up and deal with WaSP as experts. That’s gonna be a problem, since I guarantee that Freedom Scientific developers will never have heard of WaSP and could not generate an off-the-cuff definition of Web standards at gunpoint. Freedom Scientific actually definitely does need (re)education on Web standards, and they should just sit there and listen without resorting to ashtray-heaving shitfits.
Popularize non-braindead browsers among people with disabilities. Start with groups who have little or no need for adaptive technology, like deaf people. (That may require help from what is now the outside world.
deaf.BrowseHappy.com, anyone?) Get them using better browsers to begin with. Then work on making adaptive technology work better with non-braindead browsers, as I shall now explain.
Decouple blindness from IE. It’s very hard to explain to long-term screen-reader users that there is no actual inviolable configuration of the universe that compels them to use Windows and Internet Explorer. (Then again, I’ve never met a group that clings more tenaciously to myths than screen-reader users. I mean, reading PDFs is impossible or costs “$1,000+”… right?)
It’s always surprising for this group to learn about the completely free Solaris 10 operating system, with its many accessibility features, or about VoiceOver on Macintosh (as significantly in need of improvement as VoiceOver is). It’s my impression that almost none of this group has even heard about non-braindead browsers, chiefly Opera and Firefox.
It is now just barely possible to use Jaws with Firefox. (You can also get Firefox to talk, and one of those projects has the best name in software-development history: FoxyVoice.) GW Micro will evidently make the next version of Window-Eyes work with Firefox 1.1. We’ve popularized non-braindead browsers among power users and average people (even my lawyer switched to Firefox – unprompted!). We have to make it legitimately possible for people with disabilities to use the same browsers.
Carefully evaluate nonstandard code used for accessibility, and oppose it if necessary. Rich Schwerdtfeger et al. have a nice proposal to make nearly anything keyboard-accessible through the simple addition of
tabindex. But the proposal does something odd: It adds
tabindexto HTML elements that cannot, by spec, take them. And thus is the HTML spec violated. In XHTML, one could write a custom DTD to avoid the problem. (But if it so happens that you could do that only with XHTML 1.1, don’t you run into problems with serving up XHTML documents with the incorrect MIME type?)
I had plans to write a whole posting about Rich’s proposal, but in light of recent evidence, all I’m gonna say is that WaSP ATF should endorse extensions of standards that help accessibility and oppose breaking the standard even if it improves accessibility. I know: How is this different from using
embed? It probably isn’t. I just want these proposals carefully evaluated.
But do develop microformats. I’m no Tantek and he’s no Joe, but I have popularized Aries Arditi’s concept of zoom layouts and I have proposed a microformat-style hack to alert a browser or adaptive technology that such a layout exists (add
rev="zoom"to your stylesheet
link). A future version of Firefox could automatically switch to a zoom layout if it encounters such a microformat, for example. (Less desirably, somebody could develop the BlurryFox™ toolbar we talked about at @media, which you could download to engage the same function.)
Get Opera onboard. I met Aaron Leventhal, the Mozilla accessibility dæmon, at the W3C Technical Plenary. (Actually, we instant-messaged and waved to each other across the room like we were living out some kind of personal ad. I got in queue to talk to him, but gave up after I couldn’t even make eye contact.) I think it goes without saying that WaSP ATF will strike up good relations with Aaron. Of more interest is Opera, where, unbeknownst to most, a developer actually takes care of such things as UAAG evaluations.
Opera is a not-unclever company; they understand the power of niches, and niches are the true nature of the Web. Instead of merely battling IE and other desktop browsers, they also attempt to plug every other hole, chiefly through embedded systems and browsers in unlikely places. They also have some money. I think Opera would have the shortest development cycle to attain compatibility with assistive technology and the other goals WaSP ATF might have. If they’re smart, they’ll “co-brand” Opera with Window-Eyes (buy one, get one free).
If they’re really smart, they’ll realize that significant accessibility compliance might persuade the U.S. and Canadian governments to start ditching IE/Win at long last. (It’s not widely appreciated how many different operating systems the U.S. government uses, and Opera works on pretty much all of them. Exceeding Section 508 compliance while also avoiding IE/Win’s vulnerabilities is a strong combination. As for the Canadians – well, we exceed our usual levels of mediocrity. The entire federal government shuts down whenever the newest IE and Outlook worms come along.)
For this to work, however, Opera would have to unfuck its interface and rejigger its defaults. The desktop browser, on Windows and on Mac, is an absolute piece of shit the first time you boot it up, and usability is a joke. (One more time, people: When I close a tab [which is what they’re called; they aren’t “windows”], bring me to the next tab, not the previous one.)
Opera has a fanboy attack squad whose viciousness, irrationality, and tenacity rivals Scientologists’, but I’m not willing to subject people with disabilities to the default interface these fanboys ferociously defend.
(By the way, I cannot get the guy who works on set-top boxes at Opera to understand the concept of improved fonts. It’s completely baffling why I can’t get this across. I don’t recall having such a hard time communicating between Standard English and Business English since the last time I talked to a marketer at Nike.)
Get Apple onboard. And I don’t just mean Hyatt, who is very conscientious in learning about accessibility. (We’ve had many instant-message conversations. Do you have any idea how important one feels explaining the HTML spec to Dave Hyatt?) The VoiceOver team is understaffed, and VoiceOver really does not play well with Safari, let alone other browsers. I have not had much of an interaction with Apple staff who allegedly work on adaptive technology; in fact, it’s nearly impossible to get an E-mail answered.
A solution is to make friends with the Webkit accessibility developer at Apple. Such a person exists, but Hyatt won’t tell me who he or she is, and he or she does not obviously have a Weblog. A great many problems could be solved through that person, I suspect.
I would also suggest that ATF place iTunes Music Store accessibility on its to-do list. It doesn’t run in a browser and it’s not HTML, but it acts like a browser and looks like HTML. And, like iTunes itself, it works rather poorly with adaptive technology.
Find out what Adobe’s doing. I don’t mean with GoLive. It is by no means a secret that a developer works on WCAG and a marketing person works on ATAG. (Molly has names and addresses.) They’re both concerned with PDF, but so should the Web Standards Project, as PDF is a published standard in widespread use. Moreover, they know people who know people.
Give WAI a reality check. How’s WCAG 2 coming, you ask? Things aren’t getting that much better. There are still too few of us in the development group and they tend to have all the wrong kinds of expertise (e.g., expertise in writing long, discursive, academic, obstructionist, shark-jumping E-mails opposing the adoption of standard terms used in the industry). WCAG 2 has only a slightly lower chance of showing up a day late and more than a dollar short than it did when I wrote the article for Zeldman.
But WCAG isn’t the end of the story. As I keep pointing out, nothing at all complies with ATAG, and UAAG compliance is poor no matter how you cut it. (It is no cause to celebrate when most products assessed meet maybe three-quarters of the guidelines. Perhaps that indicates the guidelines are one-quarter too tough. But let’s not pretend we have the same level of compliance as, say, browsers do with HTML 4.)
I think WaSP should task MCMayTechnoDanceRemix with improving ATAG and UAAG support. After all, until early next week, that’s his day job already. In fact, I’ll go so far as to say that for the first year of its development, the only WAI specifications the ATF should concentrate on are ATAG and UAAG. Those need the most help.
Don’t rely on NCAM. Can we not fob everything off to WGBH, please? I made the mistake in the year 2000 B.B.R. of hooking Macromedia up with them, and it’s been downhill ever since.
Test CSS layouts. As I told my esteemed Australian colleagues, we don’t have a clue how the variations of CSS layout techniques – particularly floated elements – function in today’s adaptive technologies. This has implications for WCAG, as the Working Group – innocently, in this case – clings to 1999-era concepts like reading order and tab order. That made sense in an era of table layouts and single-column Web sites (who, me?!), but now it simply is not clear what a correct reading or tabbing order might be in a visually complex CSS layout. It’s not clear to me that there needs to be a single order at all. Reading in source-code order is hardly the only option.
It wouldn’t take long to test these, you know. The easiest thing to do is for Molly to have Peachpit send along copies of The Zen of CSS Design to all ATF members (and other relevant people, like adaptive-technology makers), and simply work through several or all of the examples listed. Another option is to try reading standardistas’ personal Weblogs. (Though most blind people – to use an example – are going to spend their time on commercial sites, we don’t have to test only with them, since the CSS constructs used are the same across the board.) The testing becomes a bit tedious when multiplied by the various products involved, which in turn limits the test location to only a few offices in the world. And one of them is – wait for it! – NCAM, whose participation is warranted.