ia play

I’ve been reading the Web Accessibility Handbook from Microsoft and HiSoftware.

Most of the document is marketing bumf but chapter 5 is a useful set of principles and guidelines. It is worth noting that Microsoft is not saying that these principles are requirements/commitments for their products. They tend to say something more vague like “[this is] an approach which Microsoft is integrating into its products”.

The principles are as follows:

Principle 1 – Making Information Perceivable
Guideline 1.1 -  Text Alternatives – Provide text alternatives for any non-text content
Guideline 1.2 – Alternatives for time-based media
Guideline 1.3 – Adaptable – Create content that can be presented in different ways without losing information or structure
Guideline 1.4 – Distinguisable – Make it easier for users to see and hear content including separating foreground from background

Principle 2 – Making User Interfaces Easy to Operate
Guideline 2.1 – Keyboard Accessible
Guideline 2.2 – Enough time – Provide users enough time to read and use content
Guideline 2.3 – Seizures – Do not design content in a way that is known to cause seizures
Guideline 2.4 – Navigable

Principle 3 – Making information understandable
Guideline 3.1  – Readable
Guideline 3.2 – Predictable
Guideline 3.3 – Input Assistance – Help users avoid and correct mistakes

Principle 4 – Making Information work reliably with user tools
Guideline 4.1 – Compatible – Maximise compatibility with current and future user agents, including assistive technologies

I could comment on how well SharePoint lives up to these principles but that doesn’t seem the right way to end such a lovely snowy week.

We’re starting the website phase of our programme of work. The intranet and Teamsites haven’t launched yet but development is wrapping up. There’s still testing, content migration, and training going on so that is hampering our ability to spend as much time on the website planning as I would like.

There are reasons to be optimistic that this phase will run more smoothly than the earlier two:

• we’re using the same supplier and methodology and technology so we should be able to correct ‘mistakes’ we made previously
• we’ll re-use some functionality from earlier phases
• our content authors more likely to write their content in time – the web is always more motivating than an intranet!

On the otherhand:

• the web is much higher profile, with many more stakeholders and the look and feel will be a more significant issue
• accessibility could be even more challenging as we have to design for many different access technologies rather than the RNIB supported ones for staff.

Wish me luck!

We’re moving onto a relaunch of the RNIB website. Work started (and paused) before I joined the RNIB so I’ve inherited a proposed new navigation structure.

To put the proposals in context I’ve been analysing typical navigation and tool bars on 18 charity websites. There seems to be a reasonably typical pattern of one main navigation bar, a secondary navigation bar and a utility toolbar which is often but not always in the footer.

The pattern for each bar is roughly as follows:

Main ‘charity’ bar
About Us – Get Advice – Learn About – Donate – Get Involved – News – Professionals resources – Shop

Extra ‘special audiences’ bar
For Children & Teachers – Media – Jobs

Utility bar
Accessibility – Contact Us – Help – Privacy – Terms & conditions – Site map – Global/associate sites

The terminology on the charity bar is usually tailored to the charity’s main area of activity e.g rather than Get Advice it might be Health Advice. The charity bar also occasionally included a key scheme and a link to local services but these weren’t common enough to make the cut for my pattern.  The special audiences bar is an interesting feature that seemed common on the sites.

(Charities covered: Oxfam, Christian Aid, Amnesty, Save the Children, Action Aid, Guide Dogs, Action for Blind People, Cancer Research, British Heart Foundation, Blood Pressure UK , Help the Aged, Action for Children, Barnados, Mencap, National Autism Society, Leonard Cheshire, Shelter and St Mungos)

Related posts

• keyword tools for seo and navigation design
• redesigning NTEN.org

Peter Morville has published a list of UX deliverables, complete with cute icons.

It is a nice list but the pre-amble rang warning bells for me with lots of enthusiasm for visual thinking.   I’m increasingly unable to benefit from discussions about IA deliverables in the IA community because I have to produce deliverables that are accessible to blind and partially sighted people.

The list started well in terms of accessibility with stories and proverbs, hardly typical on a list of UX deliverables. I’ve reviewed Peter’s list and compared to my early thoughts on accessbile deliverables to see if I’ve progressed at all.

• stories – fine
• proverbs – great, potentially even more memorable than stories and consequently repeatedly accessible
• personas – works, but without the poster
• scenarios  – ok without the illustrations
• content inventories – fine, but needs careful layout of excel
• analytics – presentation can be tricky. collection software often inaccessible
• surveys – much the same as analytics
• concept maps – love them but very tricky
• system maps – tricky – we tend to cobble something together in Excel/Word and use  outlining to create a hierarchy
• process flows – also tricky
• wireframes – largely doomed, if being used for a partially sighted audience then you need to think very carefully about descriptive text and the positioning of annotations
• storyboards -  definitely doomed
• concept designs – ditto
• prototypes – paper no, xHtml could be good, not sure about tools like Axure
• narrative reports – fine, although any illustrations will be a problem
• presentations – forget the powerpoint, just talk
• plans – don’t know if MS Project works for screenreaders? could probably do something that sort of works in Excel
• specifications – as for narrative reports
• style guides – depends how it is produced, some elements will be inaccessible but acceptably so
• design patterns – ok, if not reliant on images. Interactive examples might help (if screenreader friendly)

Looking at all those deliverables that are essentially flows or concept maps, makes me think a screenreader friendly mapping technique would be a big win. Even if you still won’t be able to “see it all at once”!