Part II : Best Practice IA, Technologies
Lynda : What are the common architectural blunders we make in terms of creating accessibility obstacles on websites?
Robin : The best practice in general page layout and presentation and that sort of thing that is quite well documented by people like Jakob Nielson’s work in usability – he’s quite a controversial character, but a lot of what he says makes a lot of sense – and also in the WCAG (Web Content Accessibility) Guidelines.
Basically, you need to have very consistent layout; you need to as much as possible conform with the recognised ways of doing things, the recognised behaviour of how websites work and are laid out.
But also on a page layout basis, have good use of white space. Separate your page objects, page elements by a few more pixels of white space than you might otherwise do. There’s always the temptation to cram as much above the fold as possible.
And then, from a semantic point of view, there’s a whole raft of things that you need to do so that content, functionality will be presented in a logical order for screen reader users like myself and people that use a range of assistive technologies that interpret the page in a different way than how it’s visually presented on the screen.
So there’s lots that you can do for, particularly, cognitive impairment, dyslexia and vision impaired groups smack in the middle of usability/UX. Far more in that camp than what people might think of in terms of accessibility.
Lynda : You mentioned in your presentation one column layouts – did you mean that it’s better to have one’s text sitting in a single column as opposed to the print paradigm of two or more columns?
Robin : Not necessarily. By all means, have two columns, or even three. It all comes down to how that behaves when people try, for example, to view it on a narrow screen or a small screen as in the case of a mobile device or someone who’s a magnification user, they might, for example, have their magnification set to four times, in which case they can only see a quarter of the width of the screen. They might typically reduce the width of their browser to a quarter of the screen, because if they don’t do that, then there’s going to be a lot of difficulty in always moving the focus down to the horizontal scrollbar, to scroll along a bit, go back up and look at the next bit of the quarter piece of text that they’re reading, and then go back down and scroll across again.
It’s vital that if text is zoomed up, or if people reduce the width of the browser, that the layout presentation that you’ve chosen doesn’t fall to pieces, or insist that you have it at 1024, for example.
It’s all about testing, really. And if, at the end of the day, you want to recommend that people ignore styles to give the best linearised layout for that group of people, then fine. But do make sure that the reading order is logical and you may perhaps want to offer them a style-free version, as a link using JavaScript, for example, where they don’t have to go and turn it off in the browser themselves. Just have a single column layout, you might call it.
Lynda : JavaScript’s quite controversial as well. Developers use JavaScript for a whole range of things from dropdown menus through to carousels, and very often can be inaccessible.
Robin : We’ve done a lot of work with the BBC to make sure that the widgets on their home page, the carousels on their iPlayer, EPG page, the panes that open and close in the weather page, for example, not only work for screen reader and keyboard users, but that reading order, for example when you open and close dynamic content using JavaScript or Ajax, the reading focus of the screen reader can often end up in a completely different place. So you have to do some really quite sophisticated things.
We would recommend people go and have a look at the source code on those different pages, the BBC home page, the weather results page, the Electronic Programme Guide carousel in the iPlayer area of the BBC.
As mentioned before, there’s been a lot of work done on accessible uses of JavaScript. We’re pragmatists. We don’t say don’t use JavaScript because JavaScript’s evil. There are loads of instances and examples where JavaScript can enhance usability no end, and also still be accessible. And in some cases, enhance accessibility, too. For example, by routing the reading focus of a screen reader to a particular place.
So JavaScript isn’t a bad thing by any means, but it’s probably easier to code inaccessibility into a page if you’re using a lot of JavaScript than if you were just using HTML.
Lynda : What about Flash?
Robin : Again, there are a lot of instances where people will ignore Flash plugins just because they’ve been burnt too many times in the past and they don’t want to spend time finding out that yes, this Flash is also inaccessible.
It’s a bit like PDFs in that case. They won’t even bother to open the PDF because they know from past experience that 19 times out of 20, the PDF hasn't been tagged at all. They don’t even bother opening it. So that people who have spent a lot of time and effort making their PDFs or their Flash accessible, they probably need to signpost the fact that they do tag their PDFs.
With Flash, again, we spent a lot of time and effort making sure that the iPlayer is accessible for all the categories of impairments, not just screen reader users, and it is a challenge, but there is very good documentation out there on the Adobe website, to make sure you know what you’re doing.
Certainly we wouldn’t advocate using Flash as a whole site or using it as main navigation. The old website for Ushida Findlay Architects was a good example of how not to use Flash. Their main navigation was a circle with little tiny dots and when you clicked on one of those, you got a bigger circle of smaller dots rotating around the edge as sub-navigation, so you had clicking on moving targets and Flash and keyboard inaccessibility and it was a real nightmare.
You can use Flash and it can deliver really good functionality, but you can also make it really difficult.
Lynda : Do you think as a workaround for PDFs that what we can do is also offer an HTML version of the PDF?
Robin : I think a lot of people would prefer to work with the HTML version anyway, because you’re still within your browser environment, you’re not having to open a new application, you’re very familiar with all the keystrokes of getting around HTML, for example, as a screen reader user like myself. But there are some instances where you might want the portability of the PDF or you might want to encapsulate a signature or something, if it’s an official form, so there are a number of instances where you’d need to have the PDF.
For people that have a lot of PDFs and there’s a real legacy issue there, then there is a decision to be made. Do you tag all the PDFs or do you offer RTF (rich text format) or HTML alternatives, and AbilityNet, for example, offers all of those services, because we recognise that tagging a PDF isn’t always the obvious first choice.
Part III : Demonstrating Accessibility Issues, Testing Tools, Audits, Benefits
No comments:
Post a Comment