Bringing Accessibility into the Development Process

Web accessibility is, in my experience, often considered late in the development process. Typically, accessibility evaluation is conducted by outside experts after the application is delivered and content is produced. This leads to issues being reported to developers late in the project, at a time when changes cost more.

In order to make accessibility development efforts more efficient I believe that accessibility has to be integrated into all stages of a project with as much automation as possible. Here are some ideas on how this can be done for the developer role.

Project roles and process

Consider the typical staffing of a web development project and how the respective roles relate to accessibility:

  • Designers create the user interface design. The design needs to be checked for visual aspects such as contrast issues, choice of color, font readability etc. The designer deliverables are often due early in the project.
  • Developers create the markup and application logic for the application. The markup has needs to be checked for technical accessibility issues such as correct markup of tables, forms, document structure etc. The developer devliverables appear throughout the project.
  • Content producers (copywriters) create text. The text has to be checked for readability issues and other language aspects. Content is often delivered towards the end of the project.

Accessibility experts typically appear at the end of the project to test the application. This is natural as it isn’t until the end that the majority of design, markup and content is available for testing.

Implications

The problem with this approach is that the time between feedback from the accessibility evaluation and the work done is too long. Proponents of agile development methods identified this a long time ago and it is typically illustrated with the cost of change curve:

Rapid feedback with an automated tool gives lower cost of change than slow feedback.

In essence, rapid feedback is easier to act upon and incurs a lower cost of change. Getting the feedback later means that you as a developer may have implemented more functionality in an inaccessible way. There may also be more dependencies developed that affect the parts that you need to change based on the late feedback.

So, if possible we would like to have a tool that provides rapid feedback throughout the development process to all project roles. By “rapid” I am referring to near instantaneous feedback to minimize context switching for the developer.

Challenges with automated accessibility evaluation tools

The challenge with accessibility testing is that many things are difficult to automate. Content, for example, is hard to do an automated assessment of. You may calculate all the readability scores you want but only real user testing will give you enough information to conclude if your content is understandable.

Contrast and color is also difficult. Developers may have used combinations of javascript, css and markup to create the final look. To have a machine understand the actual contrast ratio for a specific text may be nearly impossible if you don’t roll your own browser implementation.

Other challenges include integrating a tool into your project’s continuous integration framework. This rules out many of the web based tools available.

A proposed solution

If you haven’t heard of Raakt (The Ruby Accessibility Analysis Kit) before, there is a quick introduction on the Raakt wiki. Raakt focuses on the developer role in a project and helps developers make sure that the created markup passes a set of basic accessibility tests. It integrates with many test frameworks to become part of the automated test cycle.

The ambition is to make basic technical accessibility testing a natural part of a development project’s test suite. This will hopefully improve markup quality and minimize the number of accessibility issues found in subsequent tests. It also helps developers with little or no accessibility knowledge to get on track faster.

I would be very interested in receiving your feedback on what you think about this approach. How can accessibility become a more natural part of a development project? In your experience, would a project benefit from rapid accessibility feedback? Have you tried Raakt and did you find it useful?

References

Comments

  1. Antonio Volpon says at 2007-03-31 20:03:

    Interesting post.
    Some years ago in evolt.org i published an article in evolt.org, “” that addressed the need of considering accessibility issues in every part of the project, from the project analysis to the maintenance.

  2. Adrian Howard says at 2007-03-31 22:03:

    I quite agree :-) I’ve developed things in the past for projects similar to Raakt – unfortunately for clients without the foresight to release it to the world.

    Once you get your automated tests focussing on the easy stuff, it leaves you free to spot the other issues earlier. It also helps with developer education – since they’re exposed to many of the issues throughout the development process.

    I’m thoroughly sick of folk who want to keep accessibility / usability / whatever apart from the development process. It just helps make bad products.

  3. Rosie Sherry says at 2007-04-17 02:04:

    It’s kind of typical that the software testing is not really considered.

    From experience, typical scenario is design, develop, testing (functional, usability, accessibility), content.

    The projects I usually work on hand over sites with dummy text, it is usually down to the customer to maintain the content.

    Whilst I understand your attempt at creating a tool to identify problems straight away, automated testing is really very limited. Yes it will find some issues, but it will seriously not find many others. The problem with checklist style automation is that only the checklists are tested for, what about everything else? You may find that the focus ends up becoming on passing the automated tests rather than focusing on accessibility issues.

    What about compatibility, functionality, user scenarios, performance?

    Just like software testing, usability and accessibility should be seen as part of the development process, considered as early on as feasable. Why not treat accessibility as software testing? I’m a software tester and test for accessibility when doing my tests.

    You may find this post on the topic of software automation from James Bach of interest: http://www.satisfice.com/blog/archives/58

    Test Automation
    Rule #1: A good manual test cannot be automated.
    Rule #1B: If you can truly automate a manual test, it couldn’t have been a good manual test.
    Rule #1C: If you have a great automated test, it’s not the same as the manual test that you believe you were automating.

  4. Peter Krantz says at 2007-04-18 09:04:

    Rosie: Thank you for your comment. In my experience testers do not have direct control of accessibility during the development phase of an iteration (they may however be testing for it). That is why I didn’t include them. It is better if as many tests as possible can be automated and fixed directly by the developer before it reaches QA, right?

    Automated testing (in general) is not “very limited”. In fact regression testing a modern software development project demands automated testing.

    When you write “it will find some issues, but it will seriously not find many others” are you referring to Raakt or automated tools in general? If you are referring to the latter I think you may be misinformed on how many of these tools work. There are many tools available that automates testing of functionality (e.g. user scenarios). Developers define the testing scenario which can then be run automatically whenever there is a code change. Check Selenium for an example.

    As for automated accessibility testing I believe you are proposing a false dichotomy. Just because an automated test does not find all accessibility issues it does not make it useless. Finding some issues are better than none, right?

    Please note that I do not prepose replacing manual testing. I just want to reduce the number of issues reaching QA and thereby lower the project development costs.

  5. decimus says at 2007-08-03 09:08:

    hi,
    is there any possibility to translate this post to Polish?
    Let me know, thx

  6. Abhishek Singh says at 2007-08-17 12:08:

    Your website should meet basic industry good practice benchmarks, like valid HTML and CSS. Then, your website should meet at the very least Priority 1 (of the W3C WAI WCAG).

  7. Light says at 2007-09-28 18:09:

    decimus, I think gooogle can help you to translate.
    And thanks, good investigation.

  8. Batik Dress says at 2010-04-03 23:04:

    You know so many interesting infomation. You might be very wise. I like such people. Dont top writing.

  9. rolex サブマリーナ says at 2013-09-06 11:09:

    ビストロ クロックス

  10. yeast infection says at 2013-10-18 08:10:

    This is a topic that is close to my heart… Many thanks!
    Exactly where are your contact details though?

  11. Candida says at 2014-02-11 13:02:

    Usually I don’t learn post on blogs, however I wish to say that this write-up very compelled me to try and do so! Your writing style has been amazed me. Thanks, very nice article.

Trackbacks

Leave a comment

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Peter Krantz, peter.krantz@giraffe.gmail.com (remove giraffe).