Don’t forget the lampposts 

I was recently reviewing a ‘complete’ checklist for testing web applications but at no point in the list was accessibility even mentioned despite being quite thorough in other areas. I would like to try to kid myself that this was just an oversight but it is sadly all too common even though it has been a legal requirement for well over a decade. Of course, a legal requirement where enforcement is practically unheard of is rarely a motivation for an organisation to spend more money on something. That being said, there is strong evidence of the real business benefit to accessible services and information being available to the ten million disabled people in the UK (two million of which have sight problems), but that would be a whole other article.

When testing for accessibility is carried out, it is done so to a set of guidelines. The W3C[1] WAI[2] WCAG 2.0[3] are widely regarded as the guidelines to use, with the middle road AA standard the most sought after level. While the AA standard is quite adequate for the majority (AAA is better and readily achievable with a little extra effort), testing relying solely on the guidelines does not guarantee the final product is accessible and usable. It is entirely possible to have an accessible website that is very difficult to use.

When I was a child, my mother used to paint the front door of our house a bright colour in the belief, unbeknownst to me, that this was necessary for me to be able to find my way home from school. When I asked about our door and this was explained to me I thought that it was a really silly reason and promptly told her, “You just need to count the lampposts”.

This may seem like quite a bizarre anecdote to throw into a web accessibility article. However, my point is that…

just because you expect someone to do something one way does not mean they have not already found their own preferred way to do it.

The same applies to people with disabilities accessing websites and applications. The developers may intend a site/app to be accessed in a specific way but, particularly for non-visual users, the content order and methods they use will be quite different and vary upon personal preference.

Your test team can ensure the site/app designs follow the WAI guidelines, and that your content authors are trained in how to maintain the accessibility standards of your site/app but until you perform real user testing you will not know if you have completely succeeded in your goal.

There is no substitute for having a couple dozen people test your site with various technologies and tell you all the things that annoy them about it, as they will all do so in a slightly different way.

Many of the issues that arise during accessibility testing come from developers not being properly trained in HTML features for accessibility and implementing them incorrectly, which only serves to aggravate the user and drive them away from the site. This has become a particular problem with the increasing reliance on JavaScript without proper alternatives in place and most recently the use of ARIA[4] in HTML 5. ARIA has many potential benefits, particularly for fast navigation using screen readers, but when implemented poorly it can render a site extremely unpleasant to use.

Having worked in accessibility testing for over 13 years and having a lifetime’s experience of visual impairment I can’t help but feel depressed at times at how little regard is given to web accessibility.

The need for systems to be fully accessible will only increase due to the growth in essential services being provided via web applications.

With a little training and care, it is simple to implement accessibility at early development stages, thus providing a superior product that will benefit the customer and users alike (and fewer headaches for myself will be a nice bonus too).

If you have any comments about this topic, please a reply below or contact me by email.

Footnotes

[1] World Wide Web Consortium
[2] Web Accessibility Initiative
[3] Web Content Accessibility Guidelines 2.0
[4] Accessible Rich Internet Applications

Digital inclusion in the spotlight

Today (19th May) is the Global Accessibility Awareness Day (GAAD) and therefore a good reason to celebrate positive developments in this area. Recently there was an announcement from the European Commission that a new directive has been successfully negotiated, which mandates that public sector websites and apps are made more accessible. The above agreement is expected to be approved soon formally by the EU parliament and council, following which the member countries will have 21 months to convert it in to national legislation.

While it remains to be seen how quickly the directive gets converted into legislation, what is evident is that the political will behind this topic is gaining momentum in the European region, which gives reason to rejoice for those rooting for accessibility as a topic. For those more used to traditional references about accessibility, it should be highlighted that it is now considered part of the bigger title of “Digital Inclusion”. This area is, thankfully, getting a lot more attention as part of the drive for a Digital Single Market for the European region. Reduced operational costs, increased user satisfaction and better customer reach are just some of the key benefits that the experts have found this realises – in every sphere of business. It is apparent that the concerned policy makers of the EU commission are convinced about it.

Of course the upcoming referendum on 23rd June might change the course for the UK and, as a result, the relevance of legislation proposed by the EU commission might diminish.

Irrespective of the outcome of the referendum, the question we have before us is are we, or are we not, committed to being digitally inclusive?

We perhaps have a bit of soul searching to do as a technical / business community as to why we still have a strong prevalence of poor accessibility in websites. Why does this topic lack a voice in most discussions? Why is it so low down the priority list in every domain? Why does the disappointment for end users with disabilities not bother us? Why have we become comfortable with the inequality in this space?

In my opinion, every website is a service and this side of technology is way behind when it comes to digital inclusion. The designs built, websites developed and tested without much thought or consideration to the full spectrum of users is actually a form of discrimination that we are all a part of – often in complete ignorance, or due to project pressures or a misguided attempt to save costs. Do we realise how many sales will be lost due to inaccessibility, or how difficult it gets to complete online applications for crucial government services, or how companies fail to recruit talented people due to inaccessible job adverts?

Hopefully decisions like the one above will make this a more compelling factor to consider for service providers. Perhaps it is now time for all of us to put our hands up and get behind this topic, make it a priority in our immediate environment, and try to influence the decision makers to think about it. Not because it is a call from the EU, but for our fellow disadvantaged citizens, to reach out to them and give them the full opportunity to be a part of the on-going digital evolution.

There has been a positive update closer to home on this front, with Sopra Steria Recruitment recently announced as the new sponsor of the Business Disability Forum’s Recruitment Service Provider charter. Here’s to such measures which bring hope, good will and inclusivity in the world of technology!

Achieving consistency with style guides

Recently, I worked on a project where the client was looking to set up a style guide. In this case, they hadn’t yet set up their own branding beyond a logo, so it was a way to begin to explore typography, colour palettes and creating some elements they could carry forward to define their digital guidelines.

This took the form of a PDF with notes for developers, though could also have been developed into an online style guide, linked closely to a pattern library of elements that are common throughout their digital applications.

Defining styles creates consistency within the brand. When style guides are lacking, the application may end up combining a patchwork of styles. If several applications for the same company all have a very different look and feel, it creates confusion for the user, a lack of trust and identity in the brand and an impression of an incomplete or inconsidered final product.

Who are they for?

In terms of our practical applications, those scoping at the start of the project should be aware of the overall brand values. Style guides can be set up referencing existing brand guidelines, and used by UX and visual designers to define the look and feel of the application and developers to ensure elements are correctly fitting to the overall brand. The client can be reminded at any stage of how their values have been considered.

What can be included?

Style guides can begin in a Lean way – a pared down version with the minimum required. Some elements could include:

Logo use – application of the logo throughout different situations. Considerations may be the size, colour or position.
Tone of Voice – personality of the content. How is the copy written? Will it have a naturalistic language, or be full of specific technical speech?
Typography – the primary (or secondary) typefaces. This can be listed in terms of headings, body or other styles.
Colour palette – RGB/hex values showing primary and secondary palettes. Colours that are used throughout a system.
Imagery – photography or illustration style. This could be anything from dramatic black and white photography to complex vector background illustrations. All imagery should fit with the tone of voice.
Iconography – style and application of icons. These may be from an existing set, or specific to the product/system.
Animation – styles for the animations of different elements. For example, the way menus open/close on click, or hover effects on buttons appear. This should fit with the tone of voice, be it subtle transitions or playful background animations.

Similarly, pattern libraries, which define elements with snippets of code, can be set up to run in tandem with the style guide. A good example is Lightning Design’s system or the excellent guidance provided by GDS.

GDS Design Principles

When to use them

Style guides are best implemented early on, to reduce the amount of time required to make changes much later in the project. They don’t end, but rather organically grow, as the project expands. Keeping the style guide (and pattern library) up to date throughout the project gives consistency and consideration to the final product.

See also:

Excellent examples

Do you have any experiences of creating style guides? Leave a reply below or contact me by email.

UN-tangling accessibility

On the occasion of 70th Anniversary of the United Nations, there has been an initiative to raise awareness about the importance of web accessibility. As a measure of immediate change, the organisation has started to improve all the UN websites.

Logo: accessibility guidelines for UN websites

UN Secretary-General Ban Ki Moon’s thought-provoking article stresses the importance of eliminating digital barriers. This also includes a brief but highly effective video highlighting the importance of accessibility and this notable line:

Accessible websites benefit all visitors, not just those with disabilities. On an accessible website, the user is put at the centre of the experience.

This is a lesser known fact about accessibility. Apart from the obvious advantages of creating an inclusive environment and increased market reach, accessibility enhances the overall user experience by improved clarity and structure. One of the hidden benefits is improved search engine rating (in fact Google essentially is like a blind person looking for information). But above all, it is all about acknowledging the diversity in the end user community, accepting the fact that we are all differently-abled due to many factors.

I’m passionate about User Experience (UX) – improving the digital experience for the user, particularly for the disabled users. So to learn about the scale at which this is being taken up by UN is very energizing. It is high time that this topic garners the attention it deserves. It is legally, ethically and commercially important make technology a level ground for those with disabilities. A live example of its benefits is the legendary scientist Stephen Hawking who uses various assistive technologies to express himself. What a loss it would be for the world to not provide that opportunity to participate!

Today’s IT service providers have to sit up and think what they are losing by not getting their act together in terms of accessibility. In fact, it can be considered a discrimination for a service provider to host an inaccessible website and hence be subjected to legal action. However, rather than fearing accessibility for such reasons, there is a strong case for businesses to consider improving web accessibility because of the positives it brings with it. There have been glorious examples of businesses reaping benefits by making their websites accessible. There have also been some infamous stories about those who have paid a price for disregarding this aspect.

To be fair, there have been some examples where organisations have put accessibility on the top of their list, particularly where a new system is being built. For example, during the development of GOV.UK portal (Government Digital Service), I am told that the delivery would not get progressed to the live environment unless there was a complete approval on the accessibility aspect of it. However such examples are far and few between. Sadly, most seem to have chosen to push it down their ‘to do’ list. In some cases it is seen as too significant an area of impact on development processes and hence not to be taken too lightly. i.e., hold a lot of discussions rather than take any action. Why do they do that I wonder?

Existing websites, old technologies, ongoing business, impact on BAU?

Accessibility is not easy to understand. You need to involve people with disabilities to fully realise the problems. How easy is it to engage people from that community in the software development process?

ROI: is there really an audience or are we just going through a lot of hassle for a small minority?

We need specialist companies to do justice to this topic; can we afford to get them on board?

Well, let us face it, all these factors are actually very real. I very much empathise with the businesses in the challenges involved around accessibility. It is a long way to achieve the utopian idea of fully accessible websites across board. But to me, the first step is not the implementation – it is to develop the will to support accessibility, to include it in the thought process, to talk about it in meetings, to encourage innovation around it, to consider investing in it. In my opinion, there usually is not enough research done before concluding that it is not for now, it is a topic to be taken up some day in the future.

This actually calls for a change of perception and practices, a real determination to make disabled users feel more welcome. There are some immediate measures a business could take up to reflect an inclusive line of thought. For example, carrying out an audit on the existing websites to understand the current issues is a good starting point. Implementing easy fixes sometimes does not call for a huge investment. Publishing an accessibility statement on the website is another recommendable measure, to acknowledge that there are known issues and to offer the users a way to report the issues they are facing. There could be other innovative, technical solutions to accessibility issues. There is a lot businesses could do, if there is a will of course.

We might want to take a cue from the construction industry. In today’s age, there perhaps would be no new building without a lift or a ramp. Even in existing buildings, there have been excellent examples of creating an accessible route with minimal impact to the structure. It is perhaps very natural for architects and engineers to factor it in by default. It is perhaps a matter of time before accessibility in IT attains a level of importance it gets in building constructions. But we IT professionals can make it happen sooner – for the sake of 15% of world’s population, for the sake of equality and human rights, or perhaps for the sake of our own old age!

And how do we do that? By learning more about it, by raising awareness, by talking to our customers about it, by trying our best to include it in our proposals / web designs / user interfacing programs / testing activities. It is our choice to be just an audience to this initiative started by the UN or to be an active part of it.

Please spread the word!

What are your thoughts on web accessibility? Leave a message below or contact me by email.