An article intrigued me today on C|NET:
http://news.com.com/High-tech+photos+give+new+meaning+to+talking+pictures/2100-1041_3-5954367.html?tag=nefd.lede
This article covers a technology being developed by Zanetti Studio, which allows speech, or other audio, ot be attached to a printout using a specially manufactured printer. The prime goal of the device is to allow users to attach annotations to digital photographs that are printed out. The technology prints a magnetic strip along the photograph that can be scanned through a device to have the audio "read out". HP are also working on a similar technology, which uses a mobile phone to read out the annotation when placed alongside the paper.
What this means for accessibility is impressive. No longer do the blind have to rely on braille output from their printers, and can now experience as rich a hardcopy as users do with rich web-copy. We can spend time putting ALT tags on images, and other meta data designed to help users identify the context of an image in content, but when it gets printed out, this may get lost in the translation. This technology will open the door for speaking content, speaking meta-data such as ALT tags and I feel will level out the field of rich content between users of varying abilities.
This continues on from a previous entry at my post for 14th November 2005. It discusses the site at http://www.zoomthegroom.co.uk.
While ASP.NET 2.0 has appeared, and (finally) outputs XHTML which helps move the ASP.NET community to true accessibility, 1.1 is still around and will be for some time yet. This article covers how I developed a site using standards for mark-up, style-sheets and accessibility and includes a couple of neat tricks preened from my experience and others’ example.
Content Pages
As previously discussed, the Accessibility of a site can determine whether a user stays with your site, or leaves. If we recall the old clichés about how we grab a users attention, such as information within 3-clicks and the bulk of a page downloaded within 5 seconds, we can help improve our chances of keeping the users attention by using Accessible techniques to improve the experience and match their expectations to our content.
The site is very colour-rich, at the request of the client, so this can pose problems for colour-blindness. The site was colour-blinded tested using the tools available at http://colorfilter.wickline.org. While this is not an absolute test, and users colour-blindness can vary considerably, it can help in identifying the usefulness of colours in most situations. This is particularly important where colour conveys meaning, such as "stop" and "go" - which is oddly the biggest proportion of colour-blindness found in people when you consider the fundamental nature of the use of these colours.
The content-page of the site is shown below. I have annotated the image with numbers and modified the brightness of the image to illustrate the various points. We will compare these points to the Accessible version later.
- The links to the various parts of the site were implemented as a UL list, as discussed in point Here, they are styled to be vertically aligned, with CSS used for hover-effects.
- This second panel is used for "second-level" content, and as such is primarily used for sub-navigation and very brief text. The heading here is assigned to the H2 level. Although it is bolder and more vivid than any other heading, and is lower down the site in terms of appearance, it remains semantically correct.
- As the second level content has already been discussed as being lower down, this content is the "third-level" content, and this heading indicates this by its H3 mark-up.
- A reminder is provided about which fields are mandatory, with a coloured star to provide additional contrast. This was achieved by inserting the star inside a span, which was styled to highlight star. A SPAN tag is ideal for this as it is a neutral tag, which conveys no meaning but can be useful to highlight content in a fully rendered representation of the site. If we had use a STRONG tag for this, it would have been read incorrectly in a browser such as a speaking browser. Labels are provided, which use the same method discussed in a previous entry, Accessible Forms, Creating an Accessible Label control in ASP.NET. This combines the LABEL tag with the ASP.NET control renaming scheme to effectively link a label and its form control together.
- The rigid structure of the site results in a problem when more than a small screenful of data can be fitted on. This is overcome by using a DIV tag which has its overflow style-rule set to "auto".
div.overflow { overflow: auto; } This results in an IFRAME-style representation, allowing the user to scroll through the content - without actually using the IFRAME and the horridness that they bring with them.
Now lets consider the same page, but in the accessible / down-level representation. Although this is not by any means an effective test of Accessibility, it does provide us with a basic idea of how the site would be interpreted by a down-level browser, such as a screen-reader, a text browser such as Lynx, or maybe a mobile phone. This representation should be as readable as possible, and should not contain graphical furniture, devices or any content that is not pertinent to the content. Screen-readers have particular problems interpreting such devices which leads to confusion of the user.
By considering the same points, we can see how we have overcome some basic problems in maintaining accessibility of the site.
- The links to the various parts of the site were implemented as a UL list. Again, these are grouped correctly. Note that another link has appeared at the top of the page, which allows users to Skip Navigation. This link is useful for speaking browsers, and is used by users to avoid listening to the same links each time. This is one of two techniques to provide quicker access to the content in a site. The link simply links to a named anchor at the beginning of the level-3 content.
- This second-level content appears semantically correct as the second-heading in the flow of the content in this accessible version of the site. This highlights its position as being lower than the third level content can be achieved using nothing more than CSS. Therefore, it is important that in the flow of your HTML, the Heading tags are naturally flowing - regardless of their position on the site.
- The third-level content is identified by the H3 tag.
- As discussed, using a SPAN tag can be used to remove any emphasis on an item of content, in this case the asterisk character. Another slight difference can be seen here, which shows that we can also use a SPAN tag to hide content. Whereas the full version of the site said ".. marked with a '*'", the accessible version shows "... marked with an asterisk '*'. While not visible in this example, the binding together of a form control with its label is important for some browsers.
- The IFRAME-style approach to including more than a small screenful of content is really shown to be the best solution in this accessible view. As presentation is unimportant, styles are ignored and the previously scrollable content falls within the main content flow. This would not be possible with an IFRAME.
XHTML
The next problem to face is that to be able to effectively create a strong, web-standards site, one should use XHTML. Unfortunately, XHTML is not output by ASP.NET 1.1. Therefore, a hack has to be adopted to try and force the issue. A hack can be found at Rider Design's site. This can be installed as a DLL, and references from the Global.asax.cs file with the following code:
protected void Application_BeginRequest(Object sender, EventArgs e)
{
Response.Filter=new RiderDesign.Web.XHTMLStrictFilter(Response.Filter);
}
This is by no means perfect, as it does mangle some of the output of the site if it is overly complex. The author raises the issue that it does not work well when using Panel controls to show and hide content. I find that it can also mangle the ViewState variable, resulting in the cryptic exception "base64 string encoding error". The filter is useful for smaller,simpler sites, though.
Acknowledgements
The following resources were useful in developing and testing the site for accessibility.
- The Zen of CSS Design, by Dave Shea and Molly E. Holzschlag, New Riders, ISBN 0-321-30347-4
- Web Standards Solutions, by Dan Cederholm, Friends of Ed, ISBN 1-59059-381-2
- AccessifyForums - Advice and testing for accessibility at http://www.accessifyforum.com/.
While ASP.NET 2.0 has appeared, and (finally) outputs XHTML which helps move the ASP.NET community to true accessibility, 1.1 is still around and will be for some time yet. This article covers how I developed a site using standards for mark-up, style-sheets and accessibility and includes a couple of neat tricks preened from my experience and others’ example.
The site can be viewed at ZoomTheGroom.co.uk.
Front Page
Accessibility is about opening up content for all, but trying to maintain the best experience for the majority. This can often be quite challenging, particularly with regards sites that are rich in media such as images and video. This site relies heavily on a number of images that hold the site together. It was important to ensure that the images were maintained, but did not reduce the accessibility for lower-level browsers.
The front-page of the site is shown below. I have annotated the image with numbers and modified the brightness of the image to illustrate the various points. We will compare these points to the Accessible version later.
- The heading of the site is an image, which is itself inaccessible. This is overcome by adding an ALT tag to it, and by providing a text equivalent of the image in the down-level representation of the site. This is explained in full when we cover the accessible/down-level version of the site.
- The top-links are grouped together by virtue of a UL tag. This tag is styled so that it no longer appears as a bulleted list in the standard version of the site.
- The central image holds the entire of the page together. It is quite a large image, partly due to the area of the image, but also because the client was keen on a high quality image. Therefore, where an image would normally be "web-ified", this was tweaked to the minimum amount possible to maintain quality. This has the downside of it loading slightly slower.
- This is not actually text, but a graphic of some text. The stroke-effect was created in PhotoShop, and is a standard tool used to create contrast for text. Once again, using graphics reduces the readability of the page which impinges on accessibility. We will cover how this was overcome later.
- The links to the various parts of the site were implemented as a UL list, as discussed in point (2). This time, they are styled to be vertically aligned, with CSS used for hover-effects.
Now lets consider the same page, but in the accessible / down-level representation. Although this is not by any means an effective test of Accessibility, it does provide us with a basic idea of how the site would be interpreted by a down-level browser, such as a screen-reader, a text browser such as Lynx, or maybe a mobile phone. This representation should be as readable as possible, and should not contain graphical furniture, devices or any content that is not pertinent to the content. Screen-readers have particular problems interpreting such devices which leads to confusion of the user.
By considering the same points, we can see how we have overcome some basic problems in maintaining accessibility of the site.
- The heading of the site is an image, as shown. However, the accessible representation also renders a text-equivalent of the image, as an H1 tag. This maintains semantic mark-up and makes it easier to identify context. This extra text was hidden using a simple CSS rule:
h1 { display: none; }
- The top-links are grouped together by virtue of a UL tag. As can be seen, the accessible version renders these as a group. Notice that the standard rendered version of the site has dividers, similar to pipes (|) between each link. Using actual pipe characters - as is often the case with sites using text links in this manner - would result in the characters being rendered superfluously. As they offer no real value, other than a graphical device, they were not used. Instead, I used a right-margin to try and obtain a similar result.
- This third item is placed in t he middle of the page to illustrate its absence. The images that make up the site are pointless furniture as far as the flow of content goes, and as such, as been forfeited. This was performed by loading images that should not be regarded as content as background-images. By turning off CSS and mimicking a browser that ignores such styling, the images no longer appear:
div#frontImage { background-image: url(....); }
- As already discussed, this is rendered graphically in the standard representation. This leads to the problem of how do we provide an effective alternative. We could use an ALT tag, but this implies that the image is an image for a reason, and not just as a means of creating a graphical effect. Therefore, I used the Phark image replacement method to render the image as a background-image, but place the text off-screen in standard rendering.
#pharkImgReplaceH2 { display: block; float: none; height: 48px; text-indent: -5000px; background: url(http://www.zoomthegroom.co.uk/images/pageh2.gif) no-repeat; }
Note the text-indent property places the text off-screen by using an obscene negative value. As the downlevel version of the site ignores CSS, this rule is not implemented and the text is rendered normally, without the graphic.
- The links to the various parts of the site were implemented as a UL list, as discussed in point (2). Again, these are grouped correctly.
Benefits
By taking a bit longer in the working out of the CSS and how the content fits into the overall readability of the site, it is possible to create a readable site for those with browsers that can render graphics, and those with browsers that can't, have them turned off or use a specialised method of rendering content, such as providing a braille representation of the site.
The next installment of this entry will cover the main pages, which will include form design and how to maintain XHTML mark-up within an ASP.NET 1.1 environment.
I am aware of the broken images and will correct them shortly.
Comments disabled on this post due to spamming.
BBC Accessibility Guidelines
The BBC is an awesome site. It contains thousands of pages, relating not only to programme-related content, but also support services and resources made available as part of its public service charter. It encompasses a major International News site, comprehensive Sports coverage, tie-ins with programmes, special features such as election sites and interactive elements such as quizzes and other methods of "reaching the nation".
Therefore, it will always be difficult to implement or upgrade the site as an accessible web-site, and I feel that this is often the barrier that many companies with existing web presences face. They feel they should - and want - to do it, but they simply cannot afford the time or the investment required to do a good job. The BBC, for instance, will be forced to live with its existing content, but will want to introduce standards that will encourage and require standards compliance and best practises for future editorial content.
Good research!
The document in question is available in the BBC's Accessibility Standards and Guidelines section. (The document is available as a PDF: Accessibility Study of BBCi)
The usability study commissioned by the BBC into its own interactive services (known as BBCi) on the web follows the standard practise of asking a range of users with distinct needs to fulfil certain tasks. I won't go into too much detail what these tasks are, nor the nature of the participants in the study, suffice to say that an overall impression could be gained from these ten participants with respect to their needs in light of their experience of using other sites.
The report itself is excellent in that it not only discusses the feedback from the participants, but they also seeked interviews with external agencies and companies with regards their own accessible developments. It is good to see the open discussion of best practises and standards with other organisations. Accessibility is subjective, and therefore, it can often be of great benefit to get feedback from existing implementations into the mix.
Shortcomings
The document places the BBCi site in the "Medium Accessible" category. This category is below the "highly accessible" sites such as Google, Amazon and UpMyStreet.com, but more accessible than the "low accessible" sites such as MSN and Channel 4. I would largely agree with this placement, as the report identified that users had few problems using the site without using assistive technologies such as speaking browsers, etc. The site has been identified as having a consistent and logical navigation, which does not jump around between pages. One of the Standards documents used by the BBC (Page Layout) in developing new pages explicitly identifies the format of navigation to use, which I found to be particularly interesting.
As the site is run by a public body, it is required to comply to the Disability Discrimination Act, which requires that sites should at least reach Priority 1 in the WCAG WAI guidelines.
The real missing part of the report, and considering they stated they used the W3C WCAG WAI guidelines as a means of gauging accessibility compliance, is the neglect of the fact the site is constrained within tables. Using tables provides real confidence in the stability of a design, across desktop-based browsers, and makes integration of content within a content management system much easier than managing floating content and stylesheet-based presentation techniques. While I do not expect the site to be redeveloped from scratch, I do think that an acceptance of the need to limit the use of tables for formatting needs to be adopted.
Having said that, however, I did notice that none of the participants highlighted the fact the site was in tables as being of hindrance to their experience. I find this particularly interesting, as we are drummed in to the rule that tables are not for formatting and they make true accessibility adoption difficult. For most, tables are not a problem, resize your browser window and the developer can be confident that it will shrink and grow within the constraints they have defined. But put that in a smaller footprint, like a mobile phone, or an alternative presentation, like a speaking browser, and we start to get problems.
Looking at the problems of smaller footprints, the BBC seems to have addressed this by providing alternative mobile content. The BBC News site, for instance, provides a News on your Mobile page, which instructs the user on how to configure their portable device and access specially prepared, mobile content. But by adopting a standard "content fits all" approach, by avoiding tables, the content can be moved, hidden and emphasised in different ways according to the target platform. For instance, when reading the headlines, a two column layout is much to big for a mobile phone, so modifying the floating properties of each block can encourage the blocks to stack vertically - a useful layout for a small screen.
Speaking Browers are particularly prone to experiencing difficulty when information is read out of context. A number of utilities exist that mimic the output of a speaking browser, one of which is available as a Firefox Extension. Reading the output of this can be quite enlightening. Tables cause problems with this as they tend to be used as formatting aids, rather than semantic aids. A typical site (including the BBC site), has a header of links which is often complemented by links down a left navigation bar. Reading a page will cause the links to be read out every time, which can be tedious. Not only that, but the links will be read in the order they appear in the table, not in their semantic order as "top level navigation", "section navigation", and so on. While the BBC have addressed this to some extent by providing a "skip links" link, which a user can select when they are trawling through these links to jump to the content, a much neater way is to semantically address the issue by placing the links in an appropriate place in the HTML and using CSS to place the content in a more aesthetically useful manner. For instance, as you're likely to have browsed to the page you wanted anyway, provide the content first - then the navigation. And provide the navigation in reverse order, so the "nearest" links are read out first.
"Cheats"
Some will regard me calling these "cheats" as being off the mark, but I don't believe it is. True Accessibility is about opening up content for all, after all.
Text only versions
Text-only versions of sites always seem to me to be a waste of time, duplication and I often wonder whether the same care and attention is paid to the accuracy, usability and presentation of content in a text-only site. While modern sites are content managed, and text-only representations are often just splurged out of the database into a simpler stylesheet, you are still providing an alternative - rather than addressing the problem at the source. If I wanted text-only content, I would turn images off my browser. I would not want to find the link on the site (after having loaded the images in the first place), click it, then re-learn the use of the site in its alternative - and second best - form.
Accessibility Help
A link now exists in the top left of the BBC site that provides access to a page giving details on how to use the site in an Accessible manner. While the motivation behind this is well meant and very much appreciated, it makes me wonder why should someone need help to use an alternative version of the site? Shouldn't the site go into "Accessibility mode" if the browser doesn't support CSS, or if it is a particular media type? The browser should be used as a central point for modifying site settings, such as font size, image loading, CSS use and form handling - as this is the one thing the user will be familiar with. Providing options to Increase/Decrease text size, hide images, etc. is all very good, but every site has its own way of implementing this - if at all!
But hands up to the Beeb
As the web experience gets richer, and TV gets ever closer to the Internet, the BBC have got more adventurous in the content it provides. Interactive Content is now a standard part of the BBCi experience. CBeebies (the Childrens TV section) now has Accessible Flash Games, which is great to see. Flash can be accessible, but unfortunately, people just don't use it. Other interactive content is available, such as the last Election, which saw a number of complex Flash applications be provided to identify the different possibilities and outcomes of the election - including an interactive version of Peter Snows "swingometer". Multimedia content has also been available for some time, including live and downloaded content from TV and Radio. The BBC has made a commitment to provide captions for as much of this extra content as possible, something which a private company would find difficult to justify.
And finally ...
On the Suggestions and Guidelines page already discussed, it requires all BBC web sites to be valid HTML. Performing a validity check on that very page yields two errors: one of which is a secondary <body> tag!