Comments on Practical Plans for Accessible Architectures

Daniela DellAquila — Wed, 31 Oct 2007 13:20:43 GMT

Very interesting article! I’m translating it for my italian collegues, and I would like to publish the translation on my italian websites, obviously with a reference to original author and this website. May I have your permission?
Thank you in advance!

Ben Logan — Wed, 22 Aug 2007 20:31:05 GMT

Hi Frances

Really enojyed reading this and the comments also. Alaistair I really like your point on moving document structure to the IA level. Not sure how practical this would be though?

Cheers

Ben

Alastair Campbell — Mon, 06 Aug 2007 11:59:07 GMT

Currently my experience is that page structure is left to the HTML coder (assuming there is one), who may not be in a position to know the overall IA strategy. Sometimes there is no one in charge of front-end code, in which case the structure is usually non-existent or confusing.

Moving page structure to the IA stage/level would certainly help make it explicit in the site creation process, and make visible something that is often hidden until it’s too late.

Frances Forman — Mon, 06 Aug 2007 11:59:28 GMT

Web accessibility should be a precursor to usability and I wasn’t intending to suggest that this should be the other way round. My article’s focused on practical approaches for the design of information architectures (systems and structures for content or navigation) that will reduce known barriers to information access for people with disabilities. This means that there are more examples of ways to make information findable when considering different navigation user behaviours than there are examples of how to make Web content, at page or object level accessible. The purpose of the article is to explore strategies for maintaining & improving accessibility once foundations are in place for an accessible site. From my perspective it would be useful to know more about whether navigation efficiency can be improved for people who interact with the Web differently or choose different principal navigation routes. In some ways, the article is not just about Web accessibility, the ideas about customization strategies are also about improving access to information describing useful real world service accessibility.

I don’t think that every single link on a website ‘should always be understandable when pulled out of context’. I used the link chooser example as a starting point, because it considers how some audiences using some kinds of assistive technologies might establish their first impression or overview of a page. I think we need to know more about how and why different navigation systems work for or fail different audiences in order to determine which navigation patterns best support accessibility for known scenarios or circumstances.

Controlled vocabularies are a suggested approach because they can help organise link labeling systems so that labeling offers users more sense and coherence across a whole website. However, I’m not suggesting that all link labels are ‘controlled’ – just links in formal navigation – for some breeds of website. Semantic structure (use of headings, lists, etc is important when used effectively to convey information about page organisation and to distinguish formal navigation from links embedded in copy.

A site index can be a barrier to access or a great support aid depending on how it is used, designed and implemented. The same can be said for embedded links. Is a CMS strategy that prevents authors from adding embedded links to the copy for the sake of accessibility ill informed and related to the perceived risk of failing automated accessibility checks? Or is it a strategy that will prevent an the overall sense of structure and meaning for a site from being diluted?

Mapped controlled vocabularies can be used on a larger websites to ensure that main navigation terms, page titles and index terms are a) matched semantically and b) provide the right amount of navigational context in the right location for users’ needs. For larger sites, an information system level approach to link labeling could improve access to information for people with disabilities more effectively than a content – level approach. Using drive-through action links such as ‘read more’ or ‘more’ multiple times can be understandable or extremely frustrating for a user – it depends on structure, form and information design.

On captioning, for the service that is linked to, customers send their own written transcript and their video then receive it back with captions. I agree computers can’t caption – but I’m interested in the practicalities of captioning for projects such as meeting web casts and podcasts where currently, and sadly the more common finding seems to be that no captions are incorporated at all. What are the best resources for Web-based captioning projects – for a non technical audience?

Frances Forman — Fri, 03 Aug 2007 18:42:29 GMT

Thanks Joe – I was waiting for someone to kick off more debate : ) Link labeling is a scenario where I think understanding why the guidline was put in place originally is more useful that religiously adhering to checkpoints at the expense of avoiding, not using or working out complicated workarounds for useful contextual or embedded links.

It’s not so much a case of every single link (or heading) needing to be completely understood when pulled out of context but of knowing how to design labeling and naming systems effectively so that they best support users who don’t have an opportunity to or find it difficult to scan-read pages visually. From user testing experience, I know that some users with visual impairments really benefit from an accurate A to Z index and rely on this much more than the browse navigation on a site because structurally it is much easier to work with using something like zoom text – but what good is an index or supplementary aid if it is completely out of date? It’s all very well for guidelines to state that there should be a site index or site map but the design of this will also impact on accessibility and potentially act as a barrier to new & relevant information on a website – Out of date supplementary navigation is a usability issue but it can cause substantially more frustration for people using specific assitive technologies. Automated indexes are good solutions for large growing sites but their design can compromise access to information if link navigation labeling systems aren’t well defined. I agree that this is both a usability and accessibilty issue and I’ve read the errata suggesting it shouldn’t be considered as accessibility. However, considereing how different audiences rely on different parts of a navigation system to different extents is one way to get more people involved in discussions about how and why guidelines are changing and where accessibilty is going. Are we going to focus only on ultimate access or is it important to consider how easily different people can get to relevant content?

From an accessibility perspective, I think using repeated link names such as ‘more info’ – to link to further product descriptions, or using ‘more’ ‘more’ ‘more’ in an index of news articles that is not well defined structurally can be a barrier to access and detrimental experience for some people with disabilities whilst it is much less of a usability issue. I do see your standpoint that it is not a barrier but a hindrance / inefficiency – ie more usability – but I don’t see why we have to draw a line in the sand between supporting people with disabilities by enabling them to read / process / understand information and supporting people with disabilities by designing systems that support them more effectively in getting to relevant and useful information.

On the other hand, what does annoy me is the decision that a CMS should not allow authors to use ‘contextual link naming’ in content areas of the page for fear of delivering a site that is inaccessible by automated check. Contextual / embedded links can really help someone to get the gist of a page and futher information options available. Restraining authors choices for the sake of passing automated checks is not proactive accessibility – it is better to train editors in the importance of using good structure and writing style. The idea about using controlled vocabularies is to bring (thanks James) consistency to menu link labelling across a system. Of course, this will support all users to some degree but site orientation / sense of structure can be significantly more important for users for whom it is difficult to get a at a glance ‘birds eye view’ or to remember where a key piece of information is located. I accept that accessibility is a precursor and that equal access comes before improved access but why not consider designing for both? Why define inaccessible as ‘can’t use’ only when real life accessibility barriers can often be about the inefficiency and difficulty associated with different and alternative modes of information retrieval / wayfinding? If we’re developing for all users then shouldn’t all users’ navigation behaviours should be considered as part of the design process?

Joe Clark — Thu, 16 Aug 2007 09:43:26 GMT

I wish that well-meaning people would stop proposing that links (and headings) be understandable when pulled out of context. They aren’t out of context in HTML documents, which are based on a document tree. It may be a fun party trick for some application or other to list links or headings, but that says nothing about the actual organization of the document. Links in particular are inline elements and authors have not only a reasonable expectation but an *airtight* expectation that people will read and understand the context of those elements. This article would itself fail such a test.

I wouldn’t use anything “automated” to do with captioning. Computers can’t caption, and nobody should delude themselves otherwise.

I would be very surprised to find a CMS that can convert *from* PDF to RTF (a largely undocumented format) to XML (which browsers mostly cannot display and no person with a disability actually wants). To do that properly, the PDF would have to be tagged in the first place. PDF tags *are* XML.

Rather more importantly, the article gets the basic fact wrong: Accessibility is a precursor to usability, not the other way around. An inaccessible site is not usable for the simple reason that people with disabilities cannot *use* it. Unless of course those aren’t really the people we’re developing for.

bob a — Mon, 30 Jul 2007 15:13:07 GMT

Great article.

Simply put, a good site’s content and architecture should support various user agents and display modes – period. Whether it’s an external search engine, iPhone, or a person with a screen reader, the site’s architecture should support those modes of viewing the site. I believe IA is the missing link in the accessibility arena between guidelines and design. Nice work for putting them on the front burner for people to see here.

James Kalbach — Wed, 25 Jul 2007 07:05:36 GMT

Nice article, Frances. It is about time that Boxes and Arrows has an article on accessibility. Hopefully there will be more to come. I particularlly like your point about controlled vocabularies having a positive impact on accessibility.

Nick Besseling — Tue, 24 Jul 2007 01:01:16 GMT

Frances. You’re right… it is more about responsibility. I have often taken this responsibility on with little mandate or reward. So let’s say that it is not an individual lack of the fundamentals but more a collective one. Individual;s can’t really be responsibile if budgets, job descriptions and resources are not made available for the accessibility area.

Yes the debate in that area is an interesting one indeed. Frankly I think it is silly to limit the focus and scope of accessibility to just the more extreme ends of disability. Many users have some form of ‘disability’ even it is just simple eyesight problems or some slight colour blindness or even a lower reading age. By limitiing scope it means organisation’s are unlikely to take accessibility on board which then means we need to legislate on web design which can seem over the top to some. If we can ‘generalise’ accessibility it means it is more likely we can help the more disabled users as well. I am a firm believer that the web should be able to reach all.

So it’s best to promote accessibility as just plain common and good business sense rather than a huge hassle and compliance issue which in many cases it turns out to be.

I also think the technical limitations area is still valid. Many countries do not have good internet connections not even considering the lack of broadband. With many people also using mobile devices this too has an impact. Technical limitations are not just old technology but also new technology. It’s why having standards based design and devlopment is important.

But again you’re right that accessibility always seems to be a compromise which is why it is important to have people that advocate for full accessibility. It means that the compromise position of ‘middle ground’ isn’t too far to the other side.

Again great article.

Frances Forman — Mon, 23 Jul 2007 13:59:21 GMT

[Paul] Thanks for your comments. Section 508 is based on WAI guidelines, focusing on the content aspects of accessibility. I’m interested in what IAs could contribute to the accessibility arena in terms of recommenations with regard to the future development of authoring tool accessibility advice and guidelines. In the UK we also have PAS 178 – which is a guide to commissioning accessible websites (available from http://www.drc.org.uk/pas).

[Nick ]
“While the article covers basic concepts that should be well known to anyone designing or planning a website/web based application it continues to shock me that professionals working on large websites for huge companies have a fundamental lack of knowledge in this area.”

What I find interesting is that often, it’s not a case of lack of knowledge on the whole team’ s part but locus of responsibility. Maintaining accessibility post launch can depend on site governance and content management strategies which is perhaps why some large corporates fail, particularly when it comes to intranet accessibility.

“The key thing about acccessibility is not just that it supports a range of users who have major interaction barriers but that it supports All users”

Interestingly, not everyone in ‘Accessibility’ completely agrees with this statement – in fact the premise has become a rather intriguing debate. Some think that supporting people with old browsers and dial up is, in certain circumstances holding accessibility back. I read recently that it is not possible for a learning management system / e-learning site to be both SCORM compliant and WAI accessible – because the tracking of e-learning objects is based on a technology that is not considered accessible. The challenge is to define the compromises, strategies and customization opportunities that get around variability in user behaviour and context of use.

For more on the two sides of this accessibility debate follow the ‘Great Accessibility Camp Out’ link in the Resources section.

Nick Besseling — Mon, 23 Jul 2007 17:28:16 GMT

Having read Boxes and arrows for several years now this is the first article I’ve seen on web accessibility.

Fantastic! About time. There’s a lot of prancing about with analytical studies and overly intellectualising of simple tasks but so little on the fundamentals which many readers likely still neglect.

While the article covers basic concepts that should be well known to anyone designing or planning a website/web based application it continues to shock me that professionals working on large websites for huge companies have a fundamnteal lack of knowledge inb this area.

The key thing about accessibility is not just that it supports a range of users who have major interaction barriers but that it supports ALL users.

Sometimes this can mean something as simple as basic resizing of fonts using browser controls (which takes about a 30 second CSS change to implement) or ensuring a site can be viewed on dial-up modems.

The probelm is that the visual astheics of a site often overtakes the practical nature of interaction and readabilty (the growing stain of using light grey text over black text for example).

Websites, intranets and applications suceedd not because they look good (sure we all want stuff to look good) but on the ability for a user to interact and make a decision or take an action. Any barrier thats gets in the way of this fundamental means the site/app fails to meet it purpose and in turn this affects the bottom line of the organisation it is supposed to support.

Paul Bryan — Sun, 22 Jul 2007 15:29:01 GMT

Thanks for your article, Frances. I was mostly familiar with Section 508 accessibility guidelines (http://www.section508.gov/) but you updated and expanded my arsenal, not only on the assessment side, but on the design side as well.

Alun David — Sat, 21 Jul 2007 10:44:21 GMT

An excellent article Frances nicely explained in plain english