<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Frances Forman</title>
    <link>http://www.boxesandarrows.com/person/1244</link>
    <pubDate>Mon, 23 Jul 2007 13:59:21 GMT</pubDate>
    <description>Comments by Frances Forman</description>
    <item>
      <description>&lt;p&gt;[Paul] Thanks for your comments. Section 508 is based on &lt;span class="caps"&gt;WAI&lt;/span&gt; guidelines, focusing on the content aspects of accessibility. I&amp;#8217;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 &lt;span class="caps"&gt;PAS 178&lt;/span&gt; &amp;#8211; which is a guide to commissioning accessible websites (available from &lt;a href="http://www.drc.org.uk/pas" rel="nofollow"&gt;http://www.drc.org.uk/pas&lt;/a&gt;).&lt;/p&gt;

	&lt;p&gt;[Nick ]&lt;br /&gt;&amp;#8220;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.&amp;#8221;&lt;/p&gt;

	&lt;p&gt;What I find interesting is that often, it&amp;#8217;s not a case of lack of knowledge on the whole team&amp;#8217; 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.&lt;/p&gt;

	&lt;p&gt;&amp;#8220;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&amp;#8221;&lt;/p&gt;

	&lt;p&gt;Interestingly, not everyone in &amp;#8216;Accessibility&amp;#8217; completely agrees with this statement &amp;#8211; 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 &lt;span class="caps"&gt;SCORM&lt;/span&gt; compliant and &lt;span class="caps"&gt;WAI&lt;/span&gt; accessible &amp;#8211; 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.&lt;/p&gt;

	&lt;p&gt;For more on the two sides of this accessibility debate follow the &amp;#8216;Great Accessibility Camp Out&amp;#8217; link in the Resources section.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/practical-plans-for#content_10438</link>
      <guid>http://www.boxesandarrows.com/view/practical-plans-for#content_10438</guid>
      <pubDate>Mon, 23 Jul 2007 13:59:21 GMT</pubDate>
      <author>Frances Forman</author>
    </item>
    <item>
      <description>&lt;p&gt;Thanks Joe &amp;#8211; 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.&lt;/p&gt;

	&lt;p&gt;It&amp;#8217;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&amp;#8217;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 &amp;#8211; but what good is an index or supplementary aid if it is completely out of date? It&amp;#8217;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 &amp;#38; relevant information on a website &amp;#8211; 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&amp;#8217;t well defined.  I agree that this is both a usability and accessibilty issue and I&amp;#8217;ve read the errata suggesting it shouldn&amp;#8217;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?&lt;/p&gt;

	&lt;p&gt;From an accessibility perspective, I think using repeated link names such as &amp;#8216;more info&amp;#8217; &amp;#8211; to link to further product descriptions, or using &amp;#8216;more&amp;#8217; &amp;#8216;more&amp;#8217; &amp;#8216;more&amp;#8217; 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 &amp;#8211; ie more usability &amp;#8211; but I don&amp;#8217;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.&lt;/p&gt;

	&lt;p&gt;On the other hand, what does annoy me is the decision that a &lt;span class="caps"&gt;CMS&lt;/span&gt; should not allow authors to use &amp;#8216;contextual link naming&amp;#8217; 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 &amp;#8211; 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 &amp;#8216;birds eye view&amp;#8217; 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 &amp;#8216;can&amp;#8217;t use&amp;#8217; 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&amp;#8217;re developing for all users then shouldn&amp;#8217;t all users&amp;#8217; navigation behaviours should be considered as part of the design process?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/practical-plans-for#content_10921</link>
      <guid>http://www.boxesandarrows.com/view/practical-plans-for#content_10921</guid>
      <pubDate>Fri, 03 Aug 2007 18:42:29 GMT</pubDate>
      <author>Frances Forman</author>
    </item>
    <item>
      <description>&lt;p&gt;Web accessibility should be a precursor to usability and I wasn&amp;#8217;t intending to suggest that this should be the other way round. My article&amp;#8217;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 &amp;#38; 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.&lt;/p&gt;

	&lt;p&gt;I don&amp;#8217;t think that every single link on a website  &amp;#8216;should always be understandable when pulled out of context&amp;#8217;. 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.&lt;/p&gt;

	&lt;p&gt;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&amp;#8217;m not suggesting that all link labels are &amp;#8216;controlled&amp;#8217; &amp;#8211; just links in formal navigation &amp;#8211; 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.&lt;/p&gt;

	&lt;p&gt;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 &lt;span class="caps"&gt;CMS&lt;/span&gt; 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?&lt;/p&gt;

	&lt;p&gt;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&amp;#8217; 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 &amp;#8211; level approach. Using drive-through action links such as  &amp;#8216;read more&amp;#8217; or &amp;#8216;more&amp;#8217; multiple times can be understandable or extremely frustrating for a user &amp;#8211; it depends on structure, form and information design.&lt;/p&gt;

	&lt;p&gt;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&amp;#8217;t caption &amp;#8211; but I&amp;#8217;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 &amp;#8211; for a non technical audience?&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/practical-plans-for#content_10969</link>
      <guid>http://www.boxesandarrows.com/view/practical-plans-for#content_10969</guid>
      <pubDate>Mon, 06 Aug 2007 11:59:28 GMT</pubDate>
      <author>Frances Forman</author>
    </item>
  </channel>
</rss>
