Did you catch accessibility too?

[jeshyr]

[OK I have been meaning to post this for about a month and I keep putting it off on account of not having the right phrasing, but hey ... wrong phrasing will have to do]

My basic question is to those developers/volunteers/users of Dreamwidth who are NOT themselves users of accessibility technology...

I know that a bunch of folks here have become accessibility converts/evangelists. By which I mean that you're not just "doing accessibility" because Dreamwidth requires you to, but you're really understanding why it's necessary and important and often you're pointing this out to others in other contexts away from Dreamwidth too.

I know that a project can require people to "do" accessibility, but a project can't make people *care* about accessibility... and most projects that "do" accessibility at all are in the first category. So ... how did you come to care about accessibility, especially if Dreamwidth was involved??

I have been chatting to Liz Ellcessor who is writing a book about web accessibility specifically and wants to know about Dreamwidth's accessibility from the inside, but it's also just a thing I have been wondering about more generally too. Dreamwidth is known for "doing accessibility" well and part of that is that we have got a bunch of people fired up about it and that's a really hard thing to do!!

So how do you think you caught accessibility?

Comments

[azurelunatic]

The first inklings of it for me came with my time in the LiveJournal suggestions community. In social media sites with strong display settings, there is a perpetual debate about whose display settings should win out: the settings of the person creating the content, who may have a design aesthetic that goes beyond the text, images, other embeds, and semantic formatting, to include font, layout, and color choices -- or the person reading it, whose display choices may involve accessibility needs.

The customizable friends page set the stage for it; since the friends page was customizable to the needs of the reader, I believe that my feeling that non-semantic markup (embedded font face, size, font color, and background color choices) hardcoded in an entry was rude to the reader -- was representative of sentiments held by large parts of the Support team. This was because the Support team got the "my friend's entry is unreadable and/or breaking my friends page" requests rather often. The solution was of course that the friend could and should fix it; if the friend wanted a global change of font, the friend should adjust their journal style, not adjust the text in each entry. And of course there were always the people for whom their display preferences were not just strongly preferred, but in fact necessary for them to meaningfully take in and understand what was written at all.

So I came out of LJ Support with a vague feeling that for social media sites, the display preferences of the reader should triumph if there was a conflict (and of course the creator's display preferences should be honored when the creator is also the reader, or if the reader has not expressed any preference).

LiveJournal was of course started as a personal blogging site. But it's also a reasonably robust content management system, and thus people have used it for an array of amazing things. Roleplaying, of course, but also shops, a choose-your-own-adventure game, and (thank you, S2) Dre's infamous tic-tac-toe game. At one point Denise had a compilation of advice in her capacity as Support Manager that included the point that any change that removed a capability of the system had the likelihood of breaking at least one user's absolutely vital (to them) use of the service, because of the vast diversity of uses.

Around 2008, there were an immense number of little fixes that had gone unfixed for years at LiveJournal, to the point where I resented new features because they were using developer time that I felt would have been better allocated to fixing the things that people had been complaining about since 2003. LiveJournal had stopped accepting most external patches, so development was very constrained by the available labor of LiveJournal employees. Furthermore, the bug tracker went private, and it seemed like only problems with the existing code, and things that had been approved for labor, went into it. It felt like working in an office building that was 90% finished, but with rough, splintery boards and unsecured trip hazards -- and the construction budget was going to putting in a swimming pool while Support was running out of band-aids and had lost half their tweezers. So even accessibility-minded suggested changes sometimes made me cranky.

Dreamwidth grew out of LiveJournal. For me, at first, the difference was that LiveJournal was very bound by tradition: if it's been done that way forever, what justifies changing it? while Dreamwidth was open to change, and open to accommodating as many as practical of the really weird use cases that wouldn't break everything for everybody. The attitude to accepting bugs for development was less "no, we cannot accept this: we cannot allocate the development time" and more "yes, this change fits with our vision of the service; we don't know who will develop it or how fast, but we can include it in the plans."

It was that developmentally inclusive attitude, and the way that the little usability bugs that had been getting up everyone's collective noses for years were actually being fixed, that convinced me that a "how can we make this work" attitude for accepting user suggestions was vital.

The importer seemed to unlock a movement of content-driven design in a way that even the friends page had not. It seemed like mark was leading that once he'd got on board with the concept, and there was a switch from the idea that layouts should be something visually designed in Photoshop and then sliced up and attached to structural elements, to layouts being built by functional areas and then moved into an aesthetically pleasing order. LiveJournal's site schemes seemed to be built look-first, and then cramming all the elements into place to fit the look; Dreamwidth changed the name to "site skin" to better fit the idea of different colors and fonts being laid over the same bones sitewide.

Thus when various folks with strong accessibility needs showed up in #dw, having been attracted by the diversity statement, I was in an excellent frame of mind to help combine their needs and my understanding of the Dreamwidth gestalt. Their surprise at the warm welcome from #dw in contrast to other less accessible sites, and their stories of accessibility_fail were compelling; these people were now my friends, and I was cranky on their behalf. lightgetsin's brief study on accessibility requests for random websites was eye-opening (pun intended). Internet social justice training includes the concept of robust ally action. Since I am able to use sites that are not accessible to other users, and I don't need the accommodations, it costs me very little in effort to ask for them when they are not there already. I don't notice them in any way as keenly as someone who actually needs them would, but exposure and research of my own has trained me better than my college classes did about what is likely to be accessible and what is not.

[azurelunatic]

I also wrote an essay a few years back which touches on accessibility on DW as I saw it then: http://azurelunatic.dreamwidth.org/6389107.html