Web Accessibility Professional

Posted: April 1st, 2013 | Filed under: Accessibility, General, Web Development | 8 Comments »

As of today I have a new job and a new job description. Possibly a new career as well.

I’ve not left the BBC, a company I am very proud to work for, but instead of working for the GEL team (part of Platforms, in turn part of the Online Technology Group), starting tomorrow and for the next 12 months I will be joining Gareth Ford Williams and Henny Swan on the Future Media Accessibility team as a Senior Accessibility Specialist.

For some time now I’ve been considering the possibility of working full time within the web accessibility field and I’ve been very fortunate in being offered that chance at the BBC.

It’s going to be a big change for me. For the last 13 years I have been a full time web developer. For much of that time I’ve been interested and involved in web accessibility. Now the roles are reversed. I will be working in accessibility full time, my technical skills being the main contribution I make to the team. I’ll be writing a lot less code. None of the code I do write will be for complete features or go to production, except via developers. I’m also going to miss working with a team of developers, particularly those I’ve been with for the last 2 years. I’ve got 12 months to decide if this is right for me, and then I will either go back to my web development job or I can try and make the change permanent. Either way I’ll be giving it my best shot.

I can’t think of any job I’d rather do or anywhere I’d rather work right now. I’ll be on a team with a couple of great people who I have a lot to learn from, helping very smart developers make what in my view is one of the most important collections of sites on the web today as accessible as possible.

In other words, I have my dream job.

Thank you Henny and Gareth for making this possible for me.


CSUN 2013 notes

Posted: March 2nd, 2013 | Filed under: Accessibility, Conferences, Web Development | 1 Comment »

The 28th Annual International Technology and Persons with Disabilities Conference, better know as CSUN 2013, took place February 25 to March 2, 2013. I attended the general sessions portion and provide here the notes I took from some of the sessions I attended.


WCAG Guidelines – What about the Users?

Speakers

  • Birkir R. Gunnarsson
  • Hinni Hreinsson

Screen reader usage and trainer

  • Many users run multiple screen readers
  • 21% of users had formal training with screen readers
  • 80% use their screen reader webpage summary feature

Familiarity with landmarks, headings, and table navigation

  • 1/3 are familiar with and use landmarks
  • 60% are familiar with and use headings
  • 61% are familiar with and use table navigation hot keys to browse tables

Web page exploration strategies

  • 80% of users use tab and arrow keys to explore pages
  • 8% of users use TAB and arrow keys exclusively
  • Large part of the user base rely heavily on TAB and arrow keys to navigate a webpage
  • Most also have other means of navigating

Suggestions for improvements

  • Web developers: use markup clearly and efficiently

Back to list of sessions

Be the Fireman and not the Cop

Speaker

  • John Foliot

Current problems

  • Lack of accessibility planning / pre-planning
  • Stakeholders already on the defensive
  • Tight deadlines
  • No budget allotted
  • Content being developped without web acccessibility in mind

Resistance to change

  • Confrontation
  • Rejection
  • Avoidance
  • Insincerity

Finding the champions

  • It takes a cultural shift
  • Key is good communication and communicators

The law of the few

“The Tipping Point” by Malcolm Gladwell

  • Find:
    • ‘Connectors’ – know everyone, have done everything within the company
    • ‘Mavens’ – tech gurus, hardcore geeks
    • ‘Salesman’ – promoters, persuaders

Communication skills

  • Be likable, stay positive – all the time!
  • Connect – find mutual points of interest
  • Solve problems and build trust – teamwork starts with you
  • Create positive experiences – make learning fun
  • Identify and recruit the few

Establishing the systems to get you there

Tackle technical challenges

  • Standardise CMS use so you can solve problems in one place
  • Track bugs
  • Use frameworks to get accessibility built in
  • Create custom tools for internal use
  • Standardise evaluation tools

Tackle cultural challenges

  • Provide detailed expectations of outcomes, not dictate the solution – encourages creativity
  • Set realistic goals and expectations
  • Lay out the efforts as challenges not consequences
  • Don’t worry about the pursuit of quality – don’t let perfect be the enemy of good
  • Set timelines and milestones
  • Foster empathy and understanding
  • Brownbag events – invite actual users with disabilities

Addressing financial challenges

  • Be honest about how much it will cost
  • Scaled question – the longer you delay the more it costs

Transition towards a team based approach

http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown

  • Identify the responsible people
  • Identify bottlenecks in each group independently

Establish training and internal resources

  • Motivation – internal awards, recognition, etc.
  • Document knowledge – wiki etc.
  • Aim for consitency of implementation

Legislation, policy, and best practices

  • Accessibility is a governance issue, and a shared responsibility
  • Appeal to pride instead of fear
  • Create a policy: work with existing standards, avoid re-inventing the wheel
  • Lose legal threat as a last resource

Measuring success

  • Avoid checklist mentality
  • Avoid apprearances of making concessions and sacrifices
  • Avoid overly long and complex accessibility reports
  • Make accessibility more than a QA process
  • Work with milestonesL test early and often
  • Be specific with what you ask for but generous with what you accept
  • Celebrate successes, both great and small

Back to list of sessions

Agile and Accessibility: Theory and Reality

Speaker

  • Karl Groves

Waterfall approach of accessibility

  • Accessibility is a thing that intrudes at the end of every phase
  • If accessibility isn’t specified as part of a phase then accessibility isn’t going to get handled for that phase
  • Accessibility isn’t part of the discussion, it is an approval step

How do agile and accessibility work together?

  • Definition of Done
  • Inherently user focussed
  • Inherently quality focussed
  • Inherently collaborative

Tools and techniques

  • Test-driven development
  • Daily stand-ups
  • Definition of Done

Case Study: Fortune 100 Healthcare Company

Some Design Up Front (SDUF)

  • Spec work on what pages should look like
  • 95 initial reenderings (snippets of UI elements)
  • 9 page types
  • 10 sub-layouts

Traditional scrum

  • Accessibility team members assigned to several scrum teams
  • Before each story was considered complete it had to be cleared by accessibility team member

Deviations from the process

  • Underestimated scope
  • Underestimated resources
  • Untrained resources
  • Executive staff unwilling to adjust to meet evolving needs
  • Agile-fall!

Lessons learned

  • No project management system will assure success without knowledge and skills required to be effective
  • Accessibility can be integrated into any process
  • You must follow the process to realise the benefits
  • Time spent up front building accessible componenets and patterns is good accessibility ROI (still expect to refactor later)

Back to list of sessions

Accessibility in Firefox for Android

Speakers

  • Marco Zehe
  • Eitan Isaacson

Android versions

  • Android upgrade is slow
  • Most common version is Gingerbread (2.3)
  • Latest version, Jelly Bean (4.1 and 4.2) is 3rd most common

Android accessibility

  • Jelly Bean has very good support
  • Gingerbread and earlier have very basic support

Firefix for Android

  • Each version has improved support for native navigation options
    • D-pad navigation (2.3+)
    • Explore By touch (4.0+)
    • Gesture navigation (4.2)
  • Additional navigation options built in to Firefox
    • Keyboard quick navigation (2.3+)
    • Gesture quick navigation (2.3+)
  • Firefox adds support for native navigation options to earlier versions of Android
    • Explore by touch backported to 2.3
    • Gesture navigation backported to 2.3

Back to list of sessions

Infographics – Making Images Speak

Speaker

  • Ted Drake

Longdesc

  • Poor support
  • Hidden content for most users
  • Allows for good structure

WAI-ARIA

  • aria-labelledby or aria-describedby
  • Removes structure, treats content as a string

aria-describedby

  • Announces element as image, reads alt text
  • Can still use content hidden with display: none;
  • Long pause before content is read, easy to miss

aria-labelledby

  • Does not label element as a graphic up front, replaces content with transcript
  • Announces element as a graphic at the end of the transcript

Include transcript

  • Allows for good structure
  • Repeats content in the infographic
  • Can be visually hidden with CSS clipping

Toggle transcript

  • Provide a structured transcript
  • Hide content by defauly
  • Add control to show the content

Transcript link

  • Add visible link to transcript

Back to list of sessions

Implementing Accessibility Testing At The Enterprise Level

Speakers

  • John Foliot
  • Mitchell Evan

Testing matrix

  • Prioritise Assitive Technology / Browser combinations based on likely use and instance of problems

Test plan for each feature or page:

  • How to test
  • Expected results
  • Actual results
  • Notes

Successes

  • Use a bug database, not monolithic reports
  • Browser / AT matrix

Template for future projects

  • Kickoff: confirm the plan, meet & greet
  • Ground rules for visual design
  • Collaborate with UX design
  • Visual accessibility analysis
  • Collaborate with developers
  • Test

Back to list of sessions

Mozilla Firefox OS – Mobile Open Web Platform

Speakers

  • Marco Zehe
  • Eitan Isaacson

Operating system

  • Written entirely in HTML, CSS, JS, including apps and even the web browser
  • Open source
  • Linux Kernal
  • No SDK required for development

Goals

  • Get the next billion people on to the web
  • Initial launch in Central and South American countries
  • Hardware somewhere between feature and smart phone specs for affordibility

Accessibility in Firefox OS

  • Bad news: first version won’t have a screen reader
  • A screen reader is coming soon…
  • It will share the same core accessibility engine as desktop and Android versions of Firefox

Back to list of sessions

Plain Language: Usable Content for Everyone

Speaker

  • Angela Hooker

Common content problems

  • Language that needs explanation (Shakespeare)
  • Unusual structure of language (Yoda)
  • Sometimes institutions (such as government) dictate the content
  • Overly wordy content
  • Jargon that hides meaning
  • Slang or regional terms
  • “Pedantic content” – big showy words where simple words will do
  • Forgetting the audience

Plain language is…

  • writing content that people can easily understand the first time they read or hear it
  • usable and meets users needs so they can act on it
  • not forcing your users to read content several times to understand it

How can plain language help?

  • Your users will be loyal
  • Will widen your site’s appeal, audience, and influence

WCAG 2.0 principles of accessibility

  • Plaing language supports POUR
  • Plain language is ‘Understandable’ in ‘POUR’
  • Plain language makes your content accessible for all

Plain language is not…

  • dumbed down content, it’s meeting the needs of your audience

Don’t forget…

  • People with low literacy skillls
  • Pleaople with low language proficiency
  • People with cognitive impairments
  • People with dyslexia
  • People who are Deaf or hard-of-hearing
  • People who are aging

What you can do

  • Write for your specific audience
  • Write for the average reader
  • Dont’ be clever, make it simple
  • Assume audience is intelligent but don’t assume they’re familar with your topic
  • Inverted pyramid method: put the most important information at the top and the background information below
  • Be concise – cut out excess / filler words
  • Use minimal text and short sentences
  • In print people write to tell a story, but online we should write about topics so users can complete their tasks

Mechanics

  • Write in active voice, avoid passive voice
  • Use simple verb tense and base verbs (present tense)
  • Avoid ‘hidden verbs’ such as ‘provide assistance for users’ instead of ‘assist users’
  • Use complete sentences
  • Use words and terms that your users are familiar with
  • Provide direct insturctions
  • Talk with your users: use personal pronouns
  • Avoid jargon, or explain it when necessary
  • Use ‘must’ instead of ‘shall’ in requirements

Quality

  • Test with users
  • Conduct A/B testing

Summary

  • Always consider your users’ needs first
  • Your users want to complete a task
  • Talk directly to users
  • Use everyday terms
  • Don’t follow trendy content practices
  • Each medium (mobile, dekstop, app, video, podcast) may require tailored content
  • Read your content aloud
  • Test your content
  • All of these help you incorporate accessibility throughout your project lifecyle

Back to list of sessions

Web Accessibility Apprentice

Posted: February 1st, 2013 | Filed under: Accessibility, Web Development | 8 Comments »

I think I’m pretty good at writing HTML, JavaScript, and CSS. I think I’ve got a decent idea of how people use the web. I think I know a few things about web accessibility.

I don’t think I’m a web accessibility expert. I don’t think that I should stop talking, writing, or trying to improve the knowledge of others about web accessibility.

There are many people I admire who know a lot more than I about web accessibility. Collectively they are a community of sorts. Sometimes I get to be a part of that community, and that’s nice. It would be nice if more people were included, that having an interest and desire to learn were the prerequisites, not an existing level of knowledge. I try to foster that in my own communities, such as at the place I work. There are other people who do the same, and I respect them more for it.

There is often a lack of knowledge of the fundamental aspects of web accessibility outside of the community. Lots of attempts to change that have been made by the community. It hasn’t really worked very well.

I don’t know what the answer is.

Maybe some of the people who are considered experts in mainstream web development could talk about it a bit more, perhaps not talk about it as esoteric knowledge, but as part of the normal set of skills a web developer is expected to have. They’ll probably get things wrong sometimes. They could have their content peer reviewed before they publish, but perhaps if they are getting things wrong then most developers are also getting things wrong so maybe it’s worth starting the conversation anyway.

The people who consider themselves web accessibility experts as well as those people who just have a bit of knowledge could join the conversation, perhaps take advantage of the larger audience and help more people learn.

It’s been a long time in web terms since I started out as a web developer. I was very bad at it at first. I got a lot of things wrong, and I didn’t even know it. I read articles by people I respected. I learnt that there was a right way to do things. Sometimes more than one right way. Other people I respected, and some that I hadn’t heard of but who had something to say, would discuss the benefits of each and knowledge was shared. I don’t remember reading a lot of HTML blogs, or JavaScript blogs, or CSS blogs, or accessibility blogs. They existed of course, but mostly I just read web development blogs. It seemed to work. I got better at my job.

Sometimes those people made mistakes. They still make mistakes. I know I do, even with all of the knowledge they’ve shared with me. Perhaps I, and others who have benefited from a better, more knowledgeable industry that still has a long way to go should help them in return. Yes, I should do that a lot more. I hope I’ll do that in the same way they did when they educated me: with patience and encouragement, not exclusion and criticism.

I’ve met quite a lot of the people who taught me how to do my job the right way over the years. Some of them I know well enough to have a drink with. A few of them I consider friends. I haven’t thanked them enough. I’ll start doing that more.


Accessibility is a human right

Posted: February 18th, 2010 | Filed under: Accessibility, Human Rights, Web Development | Tags: , , , | 2 Comments »

I’d like to add my own thoughts to those expressed by Vlad Alexander’s excellent article Is Web accessibility a human right?.

This is a subject I feel strongly about. A sense of morality is all that I think should be required to find the motivation to make accessible websites, the legal argument means little to me.

I his article Vlad mentions specific parts of the The Universal Declaration of Human Rights which I will expand upon, but let’s start with Articles 1, 2 and 6:

Article 1

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.

Article 2

Everyone is entitled to all the rights and freedoms set forth in this Declaration, without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status.

Article 6

Everyone has the right to recognition everywhere as a person before the law.

From this we see that human rights respect the dignity of the individual and have no limits or distinctions, and apply to everyone regardless of their status.

Next, let’s look at the three points mentioned in Vlad’s article, the right to choose where we work, the right to access education, and the right to participate in culture.

Article 23.

  1. Everyone has the right to work, to free choice of employment, to just and favourable conditions of work and to protection against unemployment.

Article 26.

  1. Everyone has the right to education. Education shall be free, at least in the elementary and fundamental stages. Elementary education shall be compulsory. Technical and professional education shall be made generally available and higher education shall be equally accessible to all on the basis of merit.
  2. Education shall be directed to the full development of the human personality and to the strengthening of respect for human rights and fundamental freedoms. It shall promote understanding, tolerance and friendship among all nations, racial or religious groups, and shall further the activities of the United Nations for the maintenance of peace.

Article 27.

  1. Everyone has the right freely to participate in the cultural life of the community, to enjoy the arts and to share in scientific advancement and its benefits.

I think that is safe to say that an accessible web is necessary to meet all of these goals in 21st century Britain, and much of the rest of the world. Article 27 elegantly does away with the argument that only commercial sites are required to be accessible.

Now, I suspect I’m starting sound rather militant about web accessibility which may seem at odds with some of the points I made in my post about Web accessibility myths, particularly Content that isn’t 100% accessible shouldn’t be published.I strongly believe that all content on the web should be accessible to all who want to access it, but I’m also a pragmatic sort of person who thinks that one of the strengths of the web, and reasons for its success, is that it is an easy platform to publish to.

I would not want to discourage a single person from publishing online, or requiring extensive knowledge of the arcane discipline of web accessibility before they do, but at the same time it is imperative that those of us who call ourselves web developers or web designers as well as the suppliers of content authoring tools do our utmost to educate others and develop responsibly.

It isn’t just the law, it is far more important than that. It is a moral obligation.


APIs and accessibility

Posted: February 3rd, 2010 | Filed under: Accessibility, Web Development | No Comments »

While there are many things that developers can do to make web applications accessible it remains true that it is near impossible to cater for the needs of all users all of the time. There are simply too many requirements to try and meet, and time pressures alone mean that your application will not be able to deal with them all.

For example, the majority of users of a site like YouTube will benefit from a clean and simple interface, with subtle use of colour which does not distract from the video being played. They may like to have other videos recommended for them to watch. Users with learning difficulties however may benefit from large buttons with strong colours so that they can easily differentiate between them; recommended videos may be an unwanted distraction.

Of course YouTube could provide two different interfaces, but would then also need to design a mechanism to switch between them and from the requirements we have already defined this may necessitate a large colourful button on a clean interface, which somewhat ruins the user experience. And this is just one extra version, it may also need to create a version for low vision users (perhaps a high contrast version), deaf users (more space dedicated to captions), motor control impaired users (larger buttons), and many more. This is not maintainable for most companies, no matter how large.

By offering an Application Programming Interface, usually referred to as an API, which allows access to content and interactions other developers can create their own interfaces catering to a specific need.

One of the best known examples of this in the accessibility world is the work that Antonia Hyde and Christian Heilmann did on Easy YouTube.

Easy YouTube is an interface to YouTube aimed at users with learning difficulties. It has large and colourful buttons, clearly explained controls and an intuitive interface which makes it easy for users to either watch a specific video or search for new videos.

YouTube and Easy YouTube player is a great video demonstrating the difference that an interface designed for a users specific needs can make.

This wouldn’t have been possible had YouTube not provided a method for accessing and interacting with their content, so the next time you are working on a new web app give some thought to providing an API.


Web accessibility myths

Posted: January 23rd, 2010 | Filed under: Accessibility, Web Development | Tags: , | 22 Comments »

There is a lot of good advice for the discerning web developer to find on the web on how to make a website accessible, unfortunately there is also plenty of bad or outdated advice out there as well. Here are a few of the myths of accessibility that you may hear.

Validation equals accessibility

Good markup is the foundation of a usable, accessible and robust website. Testing that the HTML (and CSS) that you write passes a validation test can be very useful, and in general validity is something to strive for. As my colleague (and true accessibility genius) Benjamin Hawkes-Lewis puts it, valid code is a contract between you and the browser vendors – you write valid code, they will render it correctly (in theory!).

But this is not the same as accessibility, validators do not check that alt attributes are relevant, or that link text is useful. They do not test page interactions to ensure that they are usable by all. They do not ensure that text is readable. All of these issues are more important than validation, and given a choice between accessibility and validation, accessibility should win every time. Sometimes it is necessary to ignore the specification altogether, and write invalid code. Learning when and why is something that requires experience and knowledge, along with much testing when the time come, but don’t let the idea that invalid markup is always bad put you off.

If it works with a screen reader it is accessible

I think the majority of developers and their clients have got passed the idea that visual impaired people do not use the web, however there is so much focus on screen reader users that it is easy to forget that there are other groups of users that we need to make the web accessible for.

Fortunately over the last year I have seen much more information and new tools made available for opening up the web for many more people, from YouTube’s automated captioning of videos to the interest shown at events like Standards.next with a focus on cognitive disabilities. I hope this continues.

Sites are either accessible or inaccessible

Accessibility is very subjective, even by comparing against guidelines such as WCAG 2.0 it isn’t really possible to grade how accessible a website is. Content that is highly accessible to a visually impaired user with a screen reader may be inadequate for a user who lacks fine motor control.

The point is that there is almost always room for improvement, and that it is worthwhile making small changes that improve the user experience for only a small number of people – every little bit helps.

Content that isn’t 100% accessible shouldn’t be published

There is a growing trend of criticising any content that isn’t accessible to everyone, and this is counter-productive. The web has thrived and become what it is today because it is easy to publish to, by almost everyone. We might hope for more accessible content on the web but we must not discourage publishers, for example while there is no doubt that captioning of YouTube videos is a great boon to many people I would not like to see the pressure to caption put anyone off uploading a new video. Authoring tools and automation are the key for helping small publishers and non-developers make their content accessible, and we shouldn’t criticise the author if the available tools are inadequate.

The pressure seems particularly great on developers, who apparently should be held to higher standards. Christian Heilmann mentioned this in conversation recently, talking about how developers avoid putting slide decks of presentations they have online because they are not in an accessible format. This is a situation that benefits no one.

I believe that open content that is inaccessible to 50% of people is better than content that is never published. Ideally it is published with a license that allows others to take it and convert it to different forms which may be accessible, but this isn’t possible if it only exists in a file on someone’s desktop.

In conclusion…

I guess the theme of this post is that accessibility isn’t a target to aim for, it is a goal to aspire to. There is always something that can be more accessible, always another scenario that you have yet to consider, so release that application, publish that article, do your best the first time around and learn from mistakes when things don’t go well.


Alt attributes

Posted: January 15th, 2010 | Filed under: Accessibility, Web Development | Tags: , , , , , | 7 Comments »

Alt attributes are used to provide alternate text for non-textural HTML elements, most commonly on img elements. Generally their use is quite straight forward, but it is important that the attribute value you use is appropriate to the situation. In this post I’m going to talk about a few different use cases.

Let’s start the W3C description from the HTML 4.01 specification:

Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors specify alternate text to serve as content when the element cannot be rendered normally. Specifying alternate text assists users without graphic display terminals, users whose browsers don’t support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc.

The alt attribute must be specified for the IMG and AREA elements. It is optional for the INPUT and APPLET elements.

While alternate text may be very helpful, it must be handled with care. Authors should observe the following guidelines:

  • Do not specify irrelevant alternate text when including images intended to format a page, for instance, alt=”red ball” would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (“”). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead.
  • Do not specify meaningless alternate text (e.g., “dummy text”). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output.
    play terminals, users whose browsers don’t support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc.

So in HTML 4.01 an image always requires an alt attribute, but sometimes the appropriate value may be nothing at all if the image is purely decorative, a delimiter between links which are already in a list for example. Ideally these should be moved to our presentation layer, CSS, but in the real world it is not always possible to avoid having some decorative images in markup.

Some images repeat content which is available in another form. Let me give you an example:

My dog is called Milly. She is a Cavalier King Charles Spaniel, black and brown in colour,
with a white stripe on her chin.
<img src="http://farm4.static.flickr.com/3200/2730900277_54aa8dbeda_m.jpg" width="240" height="180"
alt="Milly has a white stripe on her chin">

In this example I have described Milly and provided an image to draw attention to one of her features, a small white stripe on her chin. Both the text and the image alt attribute make reference to the stripe, but remember that alt attributes are a replacement for images, so all we are doing is repeating what has already been said. There are no circumstances that I can think of where you would deliberately write ‘..with a white stripe on her chin. Milly has a white stripe on her chin.’

Let’s try this again:

My dog is called Milly. She is a Cavalier King Charles Spaniel, black and brown in colour,
with a white stripe on her chin.
<img src="http://farm4.static.flickr.com/3200/2730900277_54aa8dbeda_m.jpg" width="240" height="180"
alt="">

There is no need to have anything other than an empty alt attribute value as the meaning of the image is conveyed in the associated text. Without the text the image doesn’t make it clear what point I am trying to make – it is only a small white stripe after all. With the image sighted users will get additional information that is difficult to convey in words alone. It is advisable to write text which describes important images in this way rather than including the content in alt attributes so that all users benefit from the description and can easily read what you point you are making even if it is not immediately obvious to them from the image.

There is a different rule for images which are the only content of a link. Links must contain textual content, so an image on its own inside a link must have an alt attribute value. In these cases both the image and the alt attribute text should describe the target of the link.

Let’s try this one more time:

My dog is called Milly. She is a Cavalier King Charles Spaniel, black and brown in colour,
with a white stripe on her chin.
<a hef="http://www.flickr.com/photos/ipouncey/2730900277/sizes/l/">
<img src="http://farm4.static.flickr.com/3200/2730900277_54aa8dbeda_m.jpg" width="240" height="180"
alt="Larger image of Milly"></a>

Here the img links to a larger version of the same image and so we write alt attribute text to explain this. The main text still describes the image so all users will understand the purpose of displaying the image, and the content of the image (a picture of Milly) suggests what the link points to. If for some reason the image is not displayed, or the user uses screen reader software, the link will still make sense.

As for the other elements which allow alt attributes you can follow the same rules – treat area elements and input elements of type=image as you would an image which is the only content of a link, and applet elements as a regular img element.

Although these guidelines seem simple, correctly describing content can make a substantial difference to usability and accessibility so it is worth spending a little time to decide on the most appropriate text for alt attributes.


Title attributes

Posted: January 8th, 2010 | Filed under: Accessibility, Web Development | Tags: , | 13 Comments »

In many articles and blog posts on web accessibility use of the title attribute is promoted. Unfortunately this isn’t the magic bullet that many developers think it is, and I will argue for its use as a last resort.

First let’s see what the HTML 4.01 spec has to say:

This attribute offers advisory information about the element for which it is set.

Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a “tool tip” (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context. For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource.

Sounds like it might be quite useful. The specification gives an example of its use:

<a href="http://someplace.com/neatstuff.gif" title="Me scuba diving">
   me scuba diving last summer
</a>

Here we start to see the problems in the way it is used. Very often a title attribute on an anchor repeats information that is already contained in link text. Supposing that the title text is read by a screen reader what additional information does it provide? Little to none in this example, and unfortunately in most other examples I have seen.

Of course just because it is used badly in an example (and in most places that it is found in the wild) doesn’t prevent it being useful in other cases. What does is the way user agents deal with title attribute values.

As the specification says title attributes are most commonly displayed in user agents (web browsers in most cases) as tooltips, but only on hover with a pointing device and not on keyboard focus. If you are a keyboard only user with a visual user agent then it is very likely that you will not see a single title.

Even if you use a mouse or other pointing device there is a good chance that you will not see title attribute content as there is no visual indication that there is content to find, so unless you are in the habit of hovering over every element on a web page just in case a title attribute is set they will often be missed. Links are the most common place to find title attributes, but even then a user has to hover over a link for a second or two before the tooltip appears thus limiting their discoverability.

What about for users of screen readers then? Sadly they fair no better. As Jared Smith of WebAIM said in a comment on a recent accessibility tips article

…the title attribute is VERY rarely read on links. Screen readers have an setting to read the screen text (the blue underlined text inside the link), the title attribute, or the longer of these two. The default is screen text and I’ve only very rarely seen users change this so that the title attribute is read. So, while it’s OK to use title attribute to provide additional advisory information (that’s what the HTML spec says title is for), do not rely on it for accessibility and don’t count on it ever being seen or read by a screen reader.

So title attributes aren’t very useful then, but does this mean they are harmful? In my opinion they can be because they give the impression to developers that their use can make content more accessible to users and this simply isn’t the case. Often I see title attributes being used to cover up for inadequacies in regular content, for example:

<a href="#" title="Information about XYZ">click here</a>

The issue here is that the link text does not provide sufficient information about the destination when it is not in its full context. The solution is to fix the link text, not to add a title attribute.

An example of an appropriate use of the title attribute is given in the Techniques for WCAG 2.0 document when it offers the following advice about using title attributes on input elements:

  • User agents will display a tool tip when the mouse hovers above an input element containing a title attribute.

  • If no label is available, JAWS and Window-Eyes speak the title attribute when the form control receives focus

    • JAWS 6.0 and later can be set to speak both label and title when the two items are different; however, very few users are aware of this setting.

    • WindowEyes 5.5 has a hot key, ins-E, that will display additional information, including the title attribute, for the item with focus.

I have one criticism of this advice however, and that is that it doesn’t make it clear that this is a technique of last resort. In a situation where a label cannot be accommodated by the visual design first consider the possibility that the visual design might be flawed rather than immediately use this technique. As with links title attributes on input elements are not displayed on keyboard focus, and only after delay on mouse hover. While for many users the layout may provide sufficient context from which to derive the purpose of an input element add a screen magnifier to the mix for a keyboard only user and we are back to content that is obfuscated. If it is possible to accommodate a label for each input element in a design then do so rather than use a title attribute.

In conclusion, whenever you are thinking of using a title attribute think carefully about whether this is the right approach – more often than not you will find that by changing your content the problem, and the need to use title, goes away. If you can find no other alternative then understand that there is no guarantee that content in a title attribute will be available to your users.

Update

There are a couple of comments that deserve a response.

As Jared points out the key phrase in the HTML specification is ‘advisory information’, however I think it can be difficult to determine what is advisory and what can, for some users, turn an unusable interaction in to a usable one. In my opinion the safest option is to assume that any potentially useful content is useful, and sometimes necessary, to all users and where possible to display it by default. Sometimes a tidy design which otherwise improves the user experience doesn’t allow for advisory information, in which case use of the title attribute is a possibility, but as I say in the post it should perhaps be a last resort. The same can apply to any situation were you want to visually hide content, for example to make it available only to screen readers by positioning it off screen – it is a great technique but be sure to understand the consequences before using it.

Thierry mentioned the problems screen magnifier users can have with title attributes. The focus of this post was how unreliably content in title attribute values is made available to users, but he is right to point this out. The issue is that when a title attribute is displayed as a tooltip it covers, and can obscure, other content. With a screen magnifier a smaller area of the page is visible at a time, the tooltip will cover a larger proportion of the visible area than normal, and can therefore get in the way that much more.


Accessibility 2.0 – A million flowers bloom

Posted: September 28th, 2009 | Filed under: Accessibility, Conferences | No Comments »

Last Tuesday, 2009-09-22, I attended AbilityNet’s Accessibility 2.0 conference at Microsoft’s London Victoria offices. Here is my writeup of the notes I took in a mostly unedited form. I hope you can make some sense of it!

You can get the speakers presentations as they become available from AbilityNet.

Greg Fields (RIM) – Designing Accessible Mobile User Interfaces

  • Use native UI components where possible.
  • Be mindful of colour and contrast; minimum 7:1 contrast.
  • Respect user preferences by inheriting global settings.
  • Error messages should help users recover from the error.
  • Context menus should have the most frequently used option as the initial focus.
  • Consistent navigation, controls, interactions throughout the application.
  • Progressive disclosure: make users aware of the number of step in a process.
  • Organise information by type, meaning, etc.
  • Limit ‘chunks’ of info to 3 to 5 items.

Christian Heilmann (Yahoo!) – Neither Technology Nor Accessibility Is Dark Magic

  • Accessibility movement does not have impact / momentum.
  • Social web can be user to spread the message.
  • WiiHab – technology making a difference.
  • Web 2.0 is for everyone, not just geeks.
  • Branding holds us back, acknowledge and work with the competition.
  • Make links understandable and predictable.
  • Knowledge + Passion = Accessibility.
  • Teaching means being open.

Access Beyond the Desktop

A panel consisting of:

  • Lucy Dodd (BBC)
  • Henny Swan (Opera)
  • Veronika Jermolina (AbilityNet)
  • Greg Fields (RIM)
  • Damon Rose (BBC Ouch)
  • Julian Harty (Google)

Greg Fields

  • Moblie surpasses landline in some markets.
  • Serverside speech recognition can work with fewer client side requirements.

Henny Swan

  • Concerned about making the same mistakes as on the desktop in 1998.
  • Crossover between mobile and desktop accessibility.
  • WAI-ARIA, CSS3, media queries, HTML5 and geolocation technologies need to be ported to mobile.
  • Progressive enhancement for mobile.

Damon Rose

  • Mobile is a ‘killer app’ for blind people.
  • Mobile sites must not destroy the web experience.

Q&A

  • Same site with mobile stylesheet.
  • Allow personalisation and port preferences or allow different preference profiles for desktop and mobile.
  • Mobile accessibility requires collaboration between hardware vendors, software vendors and site / application developers.

Lisa Herrod (Scenario Seven) – Understanding Deafness: History Language and the Web

  • 1 in 7 (about 9 million) are deaf ro hard of hearing in the UK.
  • Big ‘D’ Deaf: culturally deaf, may not speak English as a first language.
  • Little ‘d’ deaf: does not identify with the deaf community, English as first language.

Steve Faulkner (Paciello Group) – Accessibility with HTML5 and WAI-ARIA

  • HTML5 semantic elements and WAI-ARIA landmark roles do not serve the same purpose.
  • Some HTML5 enhancements can be implemented with ARIA now e.g. HTML5 ‘required’ attribute is equivalent to aria-required=”true” attribute.
  • Canvas accessibility has fail! Bolt on not built in.
  • Audio, video and canvas fallback content should be outside the element – ignore the specification advice.

Mark Boulton (Mark Boulton Design) – Inclusive Design

  • Accessibility ‘experts’ need to educate designers better.
  • Accessibility is put off as ‘someone else’s problem‘.

Saqib Shaikh (Microsoft) – Silverlight Accessibility

  • Same accessibility challenges and requirements as any other development – colour contrast, semantics, etc.
  • Detects high contrast and operating system colours.
  • Works with browser zoom.
  • Controls are ‘lookless’ – their function is separate to their appearance.

To Comply Or Not To Comply

A panel consisting of:

  • Kath Moonan (AbilityNet)
  • Bim Egan (RNIB)
  • Léonie Watson (Nomensa)
  • Mark Boulton
  • Lisa Herrod (Scenario Seven)
  • Christain Heilmann (Yahoo!)

Discussion

  • Accessible products can still have beautiful design.
  • Guidelines are a starting point not the end, and shouldn’t stop innovation.
  • Responsibility for accessibility should not just lie with developers.
  • Test early, test often, with as diverse a group of users as possible, with and without disabilities.

Summary

This was yet another great day for accessibility learning in the UK, following on from Techshare the previous week and Standards.Next at the weekend. Every presentation had something to say, and as usual it was good to get a chance to talk with like minded individuals throughout the day.

The day brought up a lot of discussion over how best to create mobile sites: same markup with a mobile stylesheet or a separate implementation based on the same content source. This is not my area of expertise, but I find it an interesting question nonetheless. I’m looking forward to hearing more on this.

There is one point I would like to comment on. Mark Boulton said that the current crop of accessibility experts, who in the main are developers, need to do more to educate designers. Kath Moonan said that developers were heroes for being the ones to learn the skills needed, and it was also said that developers should not be the only ones with whom responsibility for accessibility lies.

At the moment developers are expected to know about accessibility not just when it comes to the code they produce, but also in terms of design and content, which they are not necessarily involved in producing. While I agree that developers can help designers catch up this can’t last. Developers cannot continue to be the single point through which accessibility is researched and knowledge distributed.

It seems to me that designers need to not only take responsibility for the accessibility of their work but also for their own education. Those of us who have been thinking about such things for longer can start the ball rolling, but beyond that we should be working towards developers and designers having a basic but broad knowledge of accessibility on top of which each group builds its own specialist knowledge.


Standards.Next – Cognition and accessibility

Posted: September 24th, 2009 | Filed under: Accessibility, Conferences, Technical | Tags: , , | 8 Comments »

On Saturday, 2009-09-19, the second Standards.Next event took place at City University in London, organised by Henny Swan and Bruce Lawson. This time the subject was ‘Cognition and accessibility’, a much overlooked topic.

I had the distinct pleasure of speaking along side some remarkable and talented people: Antonia Hyde, Jamie Knight and David Owens.

There have been several good write ups of the event already, but I’ll add my thoughts as well. The ‘key points’ are what I took from each speaker, not necessarily what they intended to be the most important.

Antonia Hyde – Accessibility beyond code

Antonia has rare access to testing time with users with learning difficulties, people who benefit tremendously from the internet. The work she does is invaluable in teaching us how we, as developers, can help. As you may be able to tell I’m a big fan!

Key points:

  • Describe content and controls literally – ambiguity is a barrier to comprehension
  • Combine icons with text to re-enforce messages
  • Colour coded blocks of content or sections of a site can enhance structure

Jamie Knight and Lion – Autism, the Internet and Antelopes

Before Standards.Next Jamie was interviewed by Henny about his experience of being a web developer / designer with autism. This was eyeopening and truly astonishing – the idea that stress could affect a person’s ability to talk for the next seven months came as a shock to me.

On the day he added to this with an entertaining talk and further Q&A.

Key points:

  • Fast paced action and speech in video can be hard to follow
  • Screen readers can help process content
  • Instructions must be in a literal form

David Owens – Lessons Learned Doing Usability Testing

David has recently been involved in user testing, something that few developers are able to do enough of. It is great that he works for a company that sees the value in this, because it is something that even big organisations often skip.

Key points:

  • Users can’t always remember how to do things that they have done before
  • Font re-size widgets still have a place, even though they duplicate browser functionality
  • Put flash controls before the flash so that users are made aware of them before they give up

Me! – Content and Cognition

It has been very interesting to read what other people took from my talk. In a way I felt that I was giving a summary of many of the points the other speakers had made. It reinforced my opinion that so many of the things we need to do to make our sites usable applies to most of the groups that we, rightly or wrongly, put users in.

The points I was trying to make were:

  • Avoid distractions
  • Mix content types to reach a wider audience
  • Provide feeds or APIs to allow others to transform your content in to new forms

It also kicked off a number of interesting discussions.

  1. I advised that popup windows should be avoided. Kath Moonan added that lightboxes, which are like in-page popups, also test badly with users. It appears that Alastair Campbell may be planning some research on this matter.
  2. I advised to not create elastic layouts, because this makes font-resize work like page-zoom rather than these being separate things. This removes choice from users. Some may disagree with me but I think it is a valid argument. Mike Davies has asked me to write more about this for one of his sites, so there will opportunity to flame me at a later time.

My slides are available online.

Other posts