the online home and (not very) alter(ed)-ego of Ann McMeekin, photographer, printmaker, knitter, shoe obsessive, petrolhead and user experience architect.

Please review ATAG2.0

Posted on: November 2nd, 2009 | Filed under: asks | Tagged: | Comments Off

I’m part of the W3C’s Web Accessibility Initiative (WAI) Authoring Tools Accessibility Guidelines (ATAG) working group (phew, that’s a mouthful) and during the week, we published a new working draft of the new guidlines (ATAG2.0) along with a new “Implementing ATAG 2.0″ guide.

The official call for comments sent to the WAI Interest Group (IG) went like so:

Dear WAI Interest Group Participants,

The Authoring Tool Accessibility Guidelines Working Group invites you to comment on the updated Authoring Tool Accessibility Guidelines (ATAG) 2.0 Working Draft published 29 October 2009 at:
http://www.w3.org/TR/ATAG20/

The draft integrates revisions in response to the comments of the 21 May draft as well as a substantially revised document, Implementing ATAG 2.0 that replaces Techniques for ATAG 2.0. In this draft, the Working Group made the following substantial changes:
* Revised how authoring tools should support authors in making choices that improve accessibility.
* Revised the former Techniques document to better serve developers, and changed the title to: Implementing ATAG 2.0.

Specific changes and questions for feedback are listed in the Status section:
http://www.w3.org/TR/ATAG20/#status

ATAG defines how authoring tools should help Web developers produce Web content that is accessible and conforms to Web Content Accessibility Guidelines (WCAG) 2.0. It also defines how to make authoring tools accessible so that people with disabilities can use the tools. ATAG is introduced in the ATAG Overview at:
http://www.w3.org/WAI/intro/atag.php
ATAG is part of a series of accessibility guidelines/standards developed by WAI, which are listed in WAI Guidelines and Techniques at:
http://www.w3.org/WAI/guid-tech.html

WAI encourages you to review the update ATAG 2.0 documents and submit comments on any issues that you think could present a barrier to future adoption and implementation of ATAG 2.0. Please send comments to the publicly-archived list:
public-atag2-comments@w3.org
by 30 November 2009

For more information, see:
* How WAI Develops Accessibility Guidelines through the W3C Process
http://www.w3.org/WAI/intro/w3c-process
* Authoring Tool Accessibility Guidelines Working Group (AUWG)
http://www.w3.org/WAI/AU/

Please let us know if you have any questions. Thank you in advance for your comments.

Feel free to circulate this message to other lists; please avoid cross-postings where possible.

Regards,
~Shawn Henry and Judy Brewer, W3C WAI
On behalf of: Jutta Treviranus, Chair of AUWG, and Director of the Assistive Technology Research Center, University of Toronto
Jeanne Spellman, W3C Staff Contact for AUWG

If you’re at all interested in accessibility (or even if you’re not) and you build any kind of tool or application that can be used to create content, you really need to be having a read of these and making comments if there’s anything you have an issue with. These guidelines are an important part of the process of ensuring that web content, applications and software are accessible, and present an incredible opportunity to really lead the field in best practice, especially for CMS vendors.


Expand the Awesome: Design for a Wider Audience

Posted on: October 27th, 2009 | Filed under: shares | Tagged: , , | 33 Comments »

This is a text version (more or less) of the talk I gave at BarCampLondon 7, because I don’t think the slides will be of use to anyone who wasn’t there. It isn’t exactly what I said, because that was then, this is now, the talk wasn’t recorded and I can’t remember exactly what words I used.

There were 34 slides and I did the talk in around 20 minutes (although writing it up has taken exponentially longer, weirdly), so feel free to grab yourself a cup of tea (or other beverage of choice) before you start reading.

Read the rest of this entry »


About Accessibility Pages

Posted on: October 22nd, 2009 | Filed under: asks | Tagged: , | 6 Comments »

A while ago, I asked a question about accessibility help pages on twitter, and even set up a poll, asking “Where on the page do you put your accessibility help link?“.

I gave four options, and the results were as follows:

  • At the top, in the first few tabs/links. 44% (35 votes)
  • At the bottom, in the last few tabs/links. 25% (20 votes)
  • What accessibility help link? 29% (23 votes)
  • Other 1% (1 votes)

I’ve been meaning to blog about it for ages, and was reminded about it again today, when I looked at three or four sites in a row which had accessibility help links as the very last link on the page.

I then posted to twitter that I:

would love to see stats for how many views accessibility statements/pages that are linked at the very end of page get, vs top of page.

I was really pleased when @AndyDBryant replied:

@pixeldiva If it can wait til tomorrow, I can dig out stats for my employer’s site (accessibility link at bottom). What kind of time period?

I wasn’t expecting any particular answers to my tweet, I was really just thinking out loud, but I really would love to know how many page views accessibility pages get, regardless of their positioning.

I have a few theories about them, but I’d like a bit more data before I expand on what they are, which is where you come in.

If you work on the web, have access to statistics and have an accessibility page, I would absolutely love it if you could give me the following info:

  1. Where on the page your accessibility page is.
  2. How many views your accessibility page has had in a given time period.
  3. How many views your home page has had in that time period.
  4. What that time period is.

If you can give me the name/url of the site that would be awesome, but if you can’t for whatever reason, that’s fine.

You can also use a fake name along with your comment if you feel the need, but I’d really appreciate it if you used a real email address (it’ll only be seen by me, and I won’t use it for evil, promise) so that I can contact you for further info (if you’re happy for me to do that).

If you really feel uncomfortable posting stats publicly but still want to share, you can email me instead.

Thank you.


What’s up with #missingbodybackgroundwatch

Posted on: October 8th, 2009 | Filed under: shares | Tagged: , | 6 Comments »

I wrote a post the other day sharing a tiny tip that makes testing websites easier (go read, it’s short, I’ll wait), and in that post, called out the first site that I found that had a missing body background colour.

Since then, I’ve spotted a quite surprising number of sites that have the same affliction and have (mostly for my own edification, and with half a mind on a blog post further down the road) been posting each site to twitter using the hash tag #missingbodybackgroundwatch and today, a couple of people asked what it was all about.

So. A bit of explanation.

Working with a changed colour scheme was, for the most part, not a problem… unless the site in question had specified the text colour to be a similar shade grey (or anything else that was quite light) at which point the entire thing became almost entirely unreadable as the colour contrast all but disappeared. Doh!

A better example would be a site that specified black for its text and neglected to set white as the background colour. If anyone visits using a browser set to the default colour scheme (or using Windows or Mac default colour schemes) that’d be fine, but if, for example, someone was using a high contrast reverse colour scheme, the default browser background colour would more than likely wind up being black, combine that with black text, and it just doesn’t work.

Since a picture is worth a thousand words, here are three screenshots that illustrate why it’s a problem.

The site in question is the New Statesman (I can’t remember why I was looking at it – probably followed a link from twitter).

New Statesman (Standard Browser Default Colour Scheme)
Example 1: New Statesman viewed using the standard Firefox (cos that’s what I use) default colour scheme. Looks fine, right?

New Statesman (Different Colour Scheme)
Example 2: Viewed using a different background colour (to imitate a different colour scheme). I chose pale green because it illustrates my point better than grey. It doesn’t look too good, but at least it’s still readable.

New Statesman (High Contrast Reverse Colour Scheme)
Example 3: Viewed as it would be if a user had chosen a high contrast reverse colour scheme. Some text is readable, but lots of it isn’t (which is a bit of a problem for a newspaper/magazine site.

It’s such a tiny thing, but the impact can be huge.

So, if you’re going to specify a text colour, make sure you’ve specified an appropriate background colour too. That doesn’t mean that you have to specify a background colour on every element. Provided that somewhere underneath your text you’ve specified a background colour that has sufficient contrast against the text colour, you can let the cascade do its thing.

Obviously, if you decide to change to using light text on a dark background in an area where the rest of the site is dark text on a light background then you’ll need to specify both.

Oh, and make sure that wherever you use background images that you back them up with an appropriate background colour as well. Otherwise, all that lovely contrast disappears if, for any reason, images are not available.

I’m going to keep collecting sites with a missing body background colour, do a bit of research and write a post about it in a wee while, so in the meantime, if you feel like it, change your background to something else (in Firefox, you’ll find it in Preferences, Content, Colours, then click on the box next to Background and just pick something else from the handily provided swatch) and if you spot any, it’d be ace if you’d post them to twitter using the #missingbodybackgroundwatch hash tag.


A tiny tip that makes testing websites easier

Posted on: September 25th, 2009 | Filed under: shares | Tagged: , , | 2 Comments »

When I worked at RNIB, I changed my default desktop colour scheme because the default windows scheme gave me headaches and eye strain. The department of unintended consequences then stepped in and handed me a neat way to know whether a site was missing it’s body background colour without having to check any code, because it changed the default browser background from white to muddy grey.

Since moving to using a mac, I’ve grown used to the white default background in the browser, and this morning, had a moment of panic when I realised that I wasn’t sure if I’d specified the background colour in the templates I’d built (and which were delivered to the client) last week.

I had, of course, but I realised in that moment that it’d have been much easier if I went into the settings and changed the background colour away from white (to grey, but you could choose whatever makes you happy), just to avoid that kind of panic in future. So that’s what I did.

Disappointingly, the first site to fall at that particular hurdle was the Firefox default Google search home page.


Notes from Bristol Usability Group talk by Andrew Arch

Posted on: September 23rd, 2009 | Filed under: shares | Tagged: , , | 17 Comments »

I don’t know whether it’s just coincidence, but since I’ve been working in Bristol, there seem to have been quite a high proportion of geek events happening locally, which as well as being interesting, have given me the opportunity to meet some local folk.

Last night was the turn of the Bristol Usability Group, which I was completely unaware of until Joe and Laura (separately) told me about it via twitter, correctly thinking that it’d be right up my street.

It was.

Last night’s topic was Designing for Old(er) People and Andrew Arch, Web Accessibility and Ageing Specialist for the Web Accessibility Initiative: Ageing Education and Harmonisation Project (WAI-AGE) was presenting.

I’ve known Andrew for a few years now, since he worked for Vision Australia doing similar stuff to what we did at RNIB, and hadn’t had a chance to speak to him in a long time, so quite apart from hearing his presentation, it was really good to get a chance to catch up with him. Especially since he was at the Standards.Next event I was at on Saturday but I didn’t get a chance to talk to him then.

I took quite a few notes during Andrew’s talk, because he gave a lot of information that I wasn’t aware of, including lots of useful and interesting statistics, and assuming I can read my handwriting (not an absolute certainty, and the longer I get from having written them, the less likely it gets) I thought I’d transcribe (and share) what I wrote down.

It was an information packed presentation (and discussion afterwards) and I couldn’t physically write any faster and so I know I missed some stuff, so any errors or omissions are mine alone.

Read the rest of this entry »


Designing Accessibility Into Themes

Posted on: July 1st, 2009 | Filed under: shares | Tagged: , | 1 Comment »

I was delighted last month to spend a couple of days with Leisa Reichelt and Mark Boulton looking at the work they’re doing for the d7ux project from an accessibility point of view.

During that couple of days, we got to talking about how to make it easier for people who make Drupal themes to make them accessible, and we came up with the idea of writing a kind of hints and tips document that could be viewed online or downloaded and printed.

The resulting document – Designing Accessibility Into Themes – is now available from d7ux.org and I’ve been overwhelmed by the positive response it’s received on twitter so far. I’m even more pleased that it’s in the queue to be included in the Drupal Handbook.

It’s not an exhaustive guide to everything you should do to make a website accessible, because that would take many, many more words, but I hope it strikes the right balance of information, pragmatism and tone and gives a good overview of the main things to keep in mind if you’re designing a theme for any kind of content management system – not just Drupal.

If you’ve got any feedback on it, I’d love to hear it, and please feel free to pass it on to anyone who you think might find it useful.


Thought-provoking posts on Accessibility

Posted on: March 25th, 2009 | Filed under: shares | Tagged: | Comments Off

There have been several really thought-provoking posts about accessibility made over the last week or so, and while I’m marshalling my thoughts (and the several thousand words I’ve written in response) into something coherent, I thought it’d be worth linking to them.

Accessibility to the Face from Northtemple

Here’s my point–if your brother or sister had a disability, you would give a crap. But you don’t have to have a sibling in a wheelchair to genuinely care, even if it’s only in your work.

Empathy is what separates us from the rest of the animal kingdom. We have an ability to imagine things the way that others see them and how it makes them feel. We don’t even have to have a disability ourselves.

And from my perspective, accessibility is about giving a crap.

Accessibility is NOT a checklist.

Accessibility is about usability.

Accessibility is a paradigm shift.

Accessibility is a personal issue.

If you read none of the other links in this post, read this.

Commentary on Sign Language and Accessibility from The Deaf Perspective

Quid pro quo. The loose translation for the Latin expression is “you give me something, I give you something.” We give the world accessibility to our community, our language, and our unique perspective. In return, everybody understands more why accessibility is so important for everybody.

When is the Right Time for Accessibility from Derek’s Box of Chocolates

Is it possible to include accessibility support “too early?” I’m not saying it should be an add-on at the end of the process/project/product development cycle, but I’m very seriously wondering what the optimal time for integrating an actual accessibility implementation is? Is it enough to keep accessibility architecture in mind from the beginning, but not implement right away? Should we get the basics right first, and then build in accessibility support based on that previously envisioned architecture after we know we have a viable product? We continue to say that accessibility should happen throughout rather than just at the end, but would it actually be better if we left it out, just for a little while, at the beginning?

Is Web Accessibility a Human Rights Issue? by Wendy Chisholm

It’s important for us to recognize each other’s concerns. On the one hand we have technologists who want to create things to help make the world better–help people communicate more richly and quickly, to create technologies for self-expression and commerce. Rock on. We want you to innovate because you’re changing the world. On the other hand we have people who want to use the technologies and to participate in society. When the technologists say, “Don’t make me think about accessibility, I want to be innovative.” The response from people with disabilities can be hostile because the message from the technologists is, “I do not value you enough to include you in my innovation.”