14.0 Accessibility


We’ve said lots of times that we’re really interested in accessibility and that we’ll be keeping accessibility issues and guidelines in mind as a part of our user experience design process for D7UX, well, I’m happy to report that we are really kicking that into gear, and we’re starting by having a big pow-wow with a really expert in the field. We’re going to be spending We spent the day on Wednesday (13 May) with Ann McMeekin, an Accessibility Expert who is also an invited expert on the Authoring Tools Accessibility Guideline Working Group (AUWG). Ann is going to give us some advice on how we can contribute to making Drupal7 compliant with the impending Authoring Tool Accessibility Guidelines (ATAG) 2.0

We’re going to open up this thread to discussions around Accessibility, but first up I’d like to ‘open the floor’ to you all and give you the chance to your thoughts/issues/ideas/questions through to Ann for her consideration.

So, if there’s anything you think that you’d like us to ask Ann, or to draw her attention to, the please let us know in the comments below and we’ll include it in our discussions on Wednesday and be back here with some feedback! Ann can take a look and give you her feedback or make sure it’s being taken into account where appropriate.

Rough transcript of the video (so that you don’t have watch it if you’re not so inclined):

  • introducing Ann, a freelance accessibility consultant with about 5yrs experience, previously at RNIB . She helps people make websites better for people with disabilities and in turn for everyone
  • Why get Ann involved so early? Accessibility like Usability quite often comes to the table far too late. Ann thinks it is a great opportunity to get involved so early so that she can direct the design and production effort rather than having to ‘audit’ and require ‘rework’. Ann is able to pick out things that look like they might be problem areas so that we can design things in the best way to support good accessibility.
  • Ann has reviewed a lot of the work done to date – her initial feedback is that so far there is nothing she’s seen that has made her throw her hands up in horror. She thinks there are some really interesting things going on in what we’re doing to try to create a rich experience, but this can be challenging, but the work she’s seen so far has scope for the implementation to work for everyone – she’s confident we’ll be able to create a good UX for everyone.
  • Some of the challenges that these rich experiences pose for accessibility, esp. ajax and screenreaders. There are lots of technical challenges that don’t yet have solutions but this also poses a great opportunity to find ways to make these implementation successful. Thinking about how to implement that into the work now means that as the browser and screenreader technology improves the ‘hacks’ that are required now can simply be removed later on. The important thing is to ensure that the base level experience is a good one and that the richness is just an added extra. Basic things like form interaction, when it’s done well the ‘accessible’ experience is great, you don’t feel like you’ve got a less good experience even though you don’t have all the fancy JavaScript.
  • Authoring Tools Accessibility isn’t just about having a system that is accessible, it’s also about designing a system that helps people make good decisions about accessibility as they are building sites using Drupal. (Which is v familar to our design principle of helping people make good design/UX decisions when making sites with Drupal).

19 thoughts on “14.0 Accessibility”

  1. My main bugbear would be the current handling of field descriptions. A prime offender is file/imagefield.module – the field description isn’t even close to the field title.

    It should appear before the form input; however, there are several anomalies in the Drupal system that mean overriding this positioning using global form alterations is not really feasible. (Can’t find an article to cite for that, sorry)

  2. I’m surprised to see so much time going into accessibility when the UI and design is still so undefined. Or am I missing something?

    1. hi Bevan,

      I wouldn’t say that we’re spending ‘so much’ time on accessibility but the time does definitely need to be spent at this stage of the project rather than at the end.

      Good accessibility is like good usability – it comes from a strategic and system wide approach rather than ‘fixing stuff’ at the end.

      I know it feels a little as though there is a lot that is undefined – I think we’re a lot further along than what we’ve been able to communiate – I’m going to do a lot of work in the next couple of days rectifying that.

      thanks for your feedback.

    1. Fix the backend? Making Drupal accessible goes way beyond ‘backend’ work – it goes beyond ‘coding’ – accessibility is impacted by all kinds of interface decisions.

      We’re worrying about how Drupal looks to all kinds of people and this is one part of the process.

  3. I agree that this initiative should be taken as soon as possible in the design process.

    It is relatively easy to create syntactically correct ‘accessible’ web sites without them being visually accessible or even architecturally well designed.

    The work at this point should have profound affects on the future design of D7.

    Adding accessibility at an early stage provides a decision framework which in-turn simplifies the architecture and design.

    I look forward to following this topic.

    1. Thanks for the vote of support, Paddy.

      Seeing accessibility as something that can be “fixed” in implementation can often result in something which is technically accessible but the user experience leaves a lot to be desired (or makes it completely unusuable)… and that doesn’t even begin to cover the issues that arise when you try to shoe-horn accessibility features in at the last minute.

      So I’m really excited to have the opportunity to get involved at this stage of the project, where I get to be a collaborator rather than an auditor, and also to be able to be so open about the work we’re doing.

      Watch this space 🙂

  4. @Leisa – Your right of course. Love the work your doing. No more flippant comments from me. Accesibility and appearance are both downfalls for Drupal. Just itching to see what you come up with for themes/appearance etc.

    1. Do you have any specific concerns about the accessibility of Drupal, Simon?

      If you can itemise them (for want of a better term) then I/we can either set your mind at rest, or add them to the list of things that still need a bit of accessibility love.

      1. Great to hear your input in this process Ann. Wanted to point out the Accessibility Group that has a long series of concerns about this issue – http://groups.drupal.org/accessibility

        That being said, accessibility for contributors & administrators (ATAG) is a problem in all CMS’s. I think that Drupal 7 holds the promise of being the most accessible CMS of 2010.

        One of the big outstanding issues is CSS & display:none; that we really need to get resolved for D7 – http://drupal.org/node/58941

        I’ve got a sandbox up here which is working to demonstrate some of the accessibility patches http://drupal7.dev.openconcept.ca/

  5. An interesting question has been posted in the Accessibility group regarding on the fly validation of user input – http://groups.drupal.org/node/22183#comment-76825

    I think this merits some thought. The question relates to WYSIWYG editors but I think it can be applied to all text areas where heading elements are allowed.

    Personally I would like to see some support for ARIA roles, and a full review of techniques used to hide content, such as the collapsible fieldsets using a jQuery function that by default inserts inline CSS such as display: none.

    Great work guys, fantastic!

  6. Thanks for the pointer Jeff. I plan on hopping over and getting involved in the accessibility group too so I’ll respond over there, rather than splinter the discussion.

    I agree that support for ARIA roles would be great, but but for the moment it feels more sensible to concentrate on getting the basic interaction solid and as close to right as we can get, and then move on to the enhancements, but it’s duly noted 🙂

    On the subject of techniques for hiding/showing content – the optimum technique varies depending on the desired behaviour.

    If it’s intended to be hidden from all users, then display: none is appropriate, but if it’s something which is intended to be hidden from view but available to screen reader/non-css users, then moving it out of the viewport is more appropriate.

    Of course, like so many things, it will often depend on the specific context, which can make giving a straight answer more complicated.

    Still, it wouldn’t be any fun if we didn’t invent new ways of doing things that cause us to revisit techniques to determine whether or not they continue to be appropriate 🙂

    1. Thank-you for the reply Anne. With regards to hiding content what I would like to see is the establishment of a sort of “best practice conventions”, so that Drupal module and theme developers have a standard set of tools, perhaps classes they can use.

      The problem is there are very few conventions, and module and theme developers love inventing new classes and using 3 different techniques to do the same thing.

      If we could have a couple of classes to use such as:

      .remove {}
      .hide {}

      That would at least be a convention everyone would be familiar with and could trust, meaning we know it gives the desired behaviour.

      BTW, thanks for your input in the Accessibility theming documentation on drupal.org, must appreciated and nice to see you there!

      1. I’ve recommended a couple of CSS options to hide the text here -> http://drupal.org/node/58941#comment-1606290

        Perhaps though having something like this would help clarify the purpose:

        .remove {
        display: none;
        visibility: hidden;
        .invisible {
        overflow: hidden;
        .offscreen {
        position: absolute;
        left: -999em;
        width: 1em;
        overflow: hidden;

        I also didn’t set up a .hide class as it’s already been used so many times (and not used well).

      2. Hi Jeff,

        I think conventions are a good idea, but half the trouble (fun?) of accessibility is that it often depends on context and requires a considered decision to be made about which technique best solves the problem.

        I’ve been thinking a bit about this, and trying to identify the various use-cases and user groups/needs and have made a start with a comment (http://drupal.org/node/386462#comment-1611534) on the thread about skip links because that’s an easily identified and very specific use-case with a reasonably easy solution (that can also be easily overridden if the site builder chooses).

        With any luck that’ll be more clarifying than confusing and we can then move on to the others and perhaps reach some kind of consensus (over-optimistic? moi?) on the best way to resolve the hiding/showing content issue.

  7. Hello Leisa Reichelt,

    As I have heard, Drupal 6.12 and 5.18 released somehow I found your link.

    Thank you very much for your explanation,

    Best regards from Istanbul

Comments are closed.