Survey: Accessibility Challenges

Comment by Dan Champion — Sep 19 2005 @ 4:02 am

We’ve just completed the first version of our map browser, a very basic GIS application which lets users produce maps of any part of our county at a variety of scales. It was hard to know where to start and where to finish with accessibility. For many functions it’s possible to produce broadly equivalent services (for example a list of planned developments in close proximity to an address is a reasonable equivalent to a map plotting those developments), but for others it’s just not possible. With a lot of enhancements to this service in the pipeline it’s going to be a continual challenge.

What we really lack (and this applies for all of our developments) is an accessible body of users who can help us know where to start and more importantly when to stop working towards making this type of online service accessible.

Comment by Andrew Green — Sep 19 2005 @ 4:13 am

Visual editing in a CMS context, without question. I’ve built and supplied a CMS to a handful of customers, the most significant of whom is a local authority here in the UK. They, the law, and I all demand that a page that’s built and displayed through the CMS is as accessible as possible, and the realities of getting staff to publish to the site mean that the editing environment has to be as visual and “Word-like” as possible. There are difficulties in getting the output from a visual editor to be clean code, especially after content’s been pasted directly from Word itself, and consequently a range of filters and post-processing on the server is needed to shape up the HTML that arrives from the editor — but even this can’t cope with the fact that a visual environment encourages publishers to think visually, and to make decisions about their content based on the aesthetics of <hn> vs. a paragraph that’s just all in bold. Without an understanding of HTML, it’s hard to get an understanding of the semantics of document structure that the HTML can provide. In practical terms, the answer to I don’t like the bullets, so why can’t I just use a table for this list? really needs to be because the software won’t let you — but that’s really hard to pull off, without ending up with an environment that discourages attempts to publish in the first place.

Comment by Mike Stenhouse — Sep 20 2005 @ 10:27 am

Visual editors, as Andrew has already said. I’ve not come across a good one yet. I spent days on end last year trying to write regular expressions to strip/convert the rubbish coming out of an off-the-shelf CMS the agency I was working for had sold their client. The result was reasonable but still not good. And we got complaints back from the client that extra line spaces they were adding were being stripped etc, which we had to explain was for the good of their readers at the expense of their writers. It’s a tough one to get right.

Comment by Richard Rutter — Sep 22 2005 @ 9:31 am

Probably the most difficult subject at the moment is the matter of JavaScript, and how much we can or can’t rely on it. If we’re following WCAG then JavaScript is effectively banned; fine – we can design and build in such a way that pages degrade gracefully with JS not present. But reality says that JavaScript in software such as JAWS is partially supported. The implication is that one can follow WCAG all the way to AAA and still end up with inaccessible web pages (and not just for JavaScript issues).

And talking of such things, client buy-in for accessibility is often not the problem for me. More frequently it is their requirement for a website to pass WCAG AA (or some other arbitrary badge). They are not actually interested in whether the page is accessible, as long as it gets a AA label. Clients will even go so far as to remove a download (eg movie) because they are not willing to add captions or even a transcript and would rather take the content away than have a WCAG fail. So everyone loses.

Comment by Derek Featherstone — Sep 22 2005 @ 8:47 pm

@Dan: It does sounds like you have your hands full – any mapping related activity is always difficult when it comes to accessibility. Some items can be very straightforward, but some are down right tricky, if not impossible to grasp. As you say, that’s (theoretically) where users come in.

@Andrew: there’s a whole lot of issues wrapped up in there, not the least of which is making things easy to use and encouraging to publish. Thanks for your thoughts…

@Mike: did you say regular expressions and off-the-shelf? Ouch. I feel your pain. :)

@Richard: Hopefully, many of the issues with JavaScript will be sorted soon. I’m with you as well on badges. Its like the checklist itself – the checklist promotes rule following rather than accessibility understanding, just as the badge promotes, well, getting a badge rather than being truly accessible.

Comment by Jon Tan — Sep 23 2005 @ 12:01 pm

CMS administration is our major bottle neck in our products we’re continuing to develop. All of the off the shelf editors or editor plug-ins we have tried have major failings for accessibility. Not to mention the major failings for users or managers who have very limited XHTML skills.

Javascript and screenreader questions we have worked around using PHP only for all except the editors. The issue still remains though that for us the object is to make multiple function CMS‘s that not only produce valid, accessible content on publication but also are accessible to use for the administors too.

We will get there but the path is a stony one and there are no streetlights. Good guidelines for content publication seems to be the way forward at the moment.

Comment by Ben Buchanan — Sep 25 2005 @ 10:49 pm

The challenges which pop to mind are mostly those associated with learning materials. Academics want to create rich learning objects which are engaging for students. This often means using animation and interactives which require drag-and-drop actions by the user. They find it very hard to provide alternative content for this sort of material; and the drag and drop motion doesn’t have a satisfactory keyboard equivalent. I certainly can’t tell them to drop the animations etc, since they immediately ask why they shouldn’t provide it to the students who can use it (and realistically that’s the majority).

Also, video is quite popular; but the sheer logistical consideration of creating transcripts means they’re rarely done. Having scribed many taped interviews myself I am sypathetic – it’s extraordinarily tedious work.

Finally there’s the big-picture problem of major products – portals, learning CMS, etc – which are not accessible and cannot be modified. Often this includes things like WYSIWYG editors which use font tags and so on. Where you would normally use a very simple solution, suddenly you find you’re locked into the worst possible methodologies.

Comment by Nic — Oct 03 2005 @ 4:14 am

Not so much a particular technique for me, but a question of “what is enough”? Even following WCAG, there is so much that can be interpreted in different ways, particularly when you hit AAA, that it can be difficult to know where to “draw the line”. What meets a particular requirement, or not, that kind of thing.

And then there are conflicting standards and techniques (for example “flash, accessibility, validation, choose two”: http://www.accessify.com/2005/08/validity-accessibility-flash-choose.asp ).

Comment by Lar — Oct 03 2005 @ 8:56 am

My biggest challenge to date is with respect to navigation. The web based system I inherited had heavy frame usage. The requirement was a horizontal navigation scheme with dropdowns. The dropdowns had to span to horizontal frames so they were originally written as an applet!!!
I gave it a good test with a number of blind users but it was a no go. If you can’t navigate, you can’t even begin to use the sytem! Arrrgh!

Comment by J. J. — Oct 03 2005 @ 1:37 pm

I’d have to agree with the JavaScript. Specifically, I’m trying to implement the well-designed Invasion of the Body Switchers, but it’s just not working. I’ve even submitted my code to James Edwards, one of the founders, but haven’t heard back from him (over two months).

This also relates to the issue of designing for the mobile web and the best solution for different stylesheets. See Mike Davidson’s Make your site mobile-friendly in two minutes for more ideas.

Comment by Adam — Oct 03 2005 @ 7:12 pm

Definately working with visual CMS systems. Without a doubt.
Alot of the time its an older system that we’re refreshing (new visual design/xhtml frontend), but we’re stuck with the out of date backend.

That and clients who want *bling* in the form of javascript/AJAX and flash.

Comment by Richard — Oct 05 2005 @ 5:15 pm

I had a problem recently with some dropdown menus. They opened on hover and they worked fine. After some testing two camps came to me. The sighted folks wanted the dropdowns to not open immediately, but only after you hovered over the menu for a moment. The non-sighted folks wanted a way to close a menu after they had opened it, so they wouldn’t have to listen to all the items before moving to the next menu.

The problem turned out to be that JAWS triggers an onClick and an onMouseOver event when you press enter (or whatever key he was using) on a link. So no matter what I tried, the code to close the menu would trigger it to open again because the browser thought you were hovering over it.

After lots of tests on my part I decided the two features were mutually exclusive, and we had the dropdowns open on click rather than mouseover.

Comment by Lawrence Meckan — Oct 06 2005 @ 10:46 pm

Like Richard, my bane of existence has been Javascript dropdown menus. The other half of my accessibility woes deal with trying to make an out of the box CMS web standards compliant and accessible at the same time.

Comment by robert campbell — Oct 07 2005 @ 7:59 am

The biggest issue for us is still the education of the customer and trying to make sense of ‘how far to go’. Like Dan I’d like to use other to test our work more realistically.

For all those complaining about CMS systems that don’t produce decent output, we couldn’t agree more. Which is why after looking at many commercial and OS systems we developed our own. Can anyone tell me why MAMBO is being used by anyone ?? At least with our own CMS, if the system outputs tripe we have only ourselves to blame.

Education is still what it’s all about, developers, CMS builders and the customer.

Comment by Johan De Silva — Oct 09 2005 @ 7:01 am

With .net2 beta 2 our company is developing our own CMS to an accessible standard. It seems to be progressing really well and its only a matter of time before commercial CMS follow the same guidelines.

My own personal problems as the client side scripter/designer is that usability in screen reading is ignored while we focus too much on correct mark-up etc"¦. For example a simple list menu with say options for selecting a area of the country can have around 50 selections. For visual users this is fine they simply browse the list and select but for screen readers I am sat there for literally minutes and minutes while the screan reader reads everything and I can make my selection.

Also my company is called Eteach which simply is not pronounced correctly and would welcome a new tag to deal with this like acronym.

Comment by Karl-Johan Sjögren — Oct 16 2005 @ 2:01 pm

Making a good visual editor for use in a CMS is a real hazzle as many have already said. We are developing our own CMS at work and we have been adding tons and tons of regexps lately to clean up the code but it just isn’t enough. We also put alot of work into educating the ones that are going to work with it (the editors). The really hard part is to deliver a good solution which allow just enough visual freedom without endangering accesability and still makes the customer happy about it. Strip it down too far and they have a few input boxes and they get grouchy about it. On the other hand if you give them a huge WYSIWYG editor and they screw up semantics and give you the blame for making it to hard to control for them.

Comment by Small Paul — Oct 20 2005 @ 6:22 am

I’d agree with the issue of educating content creators on accessibility. Maming meaningful HTML can only efficiently be done by the people writing the content. Unless they’ve bought in to HTML’s particular view of document semantics, then basically, all is lost.

I’ll soon be planning training for people in my company who’ll be updating our website. But it’s definitely the challenge: I got my understanding (such as it is) of meaningful, accessible HTML from about a year of reading blogs and writing code. It’ll be interesting trying to get other people to pick up and understanding within 2 days.

Comment by Emma Kalson - littlefishwebdesign.com — Oct 26 2005 @ 10:47 am

As a web designer, my most challenging accessibility problem has occurred when I get a client asks me to maintain an existing site. Even after explaining what accessibility means legally, and the benefits it confers, most small business clients just aren’t interested – they don’t consider it essential and won’t pay for the accessibility work to be done. When designing sites from scratch, to avoid accessibility and validation issues, I find that avoiding as much javascript as possible, and separating content from markup are my two best strategies.