Post Archive
› January 30, 2004
Section 508 at odds with Web-based apps using rich interactions?
OK, this is more a point to ponder and discuss than anything else. In a UE review today, I had a coworker ask how accessibility/Section 508 was being fully addressed in my HTML mockup. Sure, I had appropriately included alt tags where appropriate and similar practices. But where I always get tripped up on this one is I often employ Javascript to hide/show rows in tables or divs or maybe the table would dynamically generate new rows when a line item was added (document.write), etc. And we believe Section 508/screen readers would balk at this sort of thing.
So the question is how do you employ sophisticated user interactions that intend to present the most successful user experience while fully addressing Section 508 compliance?
I'm one to try and work accessibility into my interaction designs but if I make this the main goal, I often end up conceiving an interaction that results in a painful, cumbersome experience for the unimpaired user, which is our biggest customer. Since our products are JSP-based, we could certainly specify that we go back to the server and reload/re-render the page every time we add a line, but reloads kill an interaction like this.
I mostly feel the problem is Section 508 does not address the domain space of Web-based applications at all. Sure there's rules for websites and rules for desktop software, but not ones for software that employs interaction sets from both. So our team is left trying to piece together a hodgepodge set of rules from both. And I'm one that is trying to push Web-based applications to look and behave more like users have come to expect from desktop applications.
So has anyone else face this dilemma? Any thoughts?
Comments
1. January 30, 2004 04:42 AM
2. January 30, 2004 06:35 AM
Mark Wubben Posted…
Do webapplications have to degrade? To what extend can you support old browsers and accessibility rules? If your webapplication depends on XMLHTTP requests, you need at least a 5th generation browser. Due to incompatibilities, however, you might be best off supporting IE6, a recent Mozilla build and perhaps Safari (as far as I know Opera isn't ready for this job).
If you are updating content dynamicly, through webservices, can you rely on screen readers to pick up these changes? Appearantly not. Now the question is, is that a problem?
Of course, if you aim for 95% compatibility, degradability and accessibility it is a problem. But will the extra work actually pay off? Developing two systems (one using webservices and the other using plain HTML POST forms) means a lot more work.
To come back to the beginning of this comment, I don't think webapplications need to degrade. They are supposed to be targetted at specific browser versions. Websites, on the contrary, ought to be accessible for everyone. I think the line between the two is pretty clear.
3. January 30, 2004 09:04 AM
Ben Scofield Posted…
I'll add a question to the growing pile:
In a rich web-based app used under normal conditions, dynamically shown/hidden/created rows are easily noticed ("Hey, the screen moved!"). Normal conditions also allow the designer/developer to draw attention to the results of dynamic operations with visual cues such as color and size, but all of this is only possible because the page under normal conditions (forgive me for the constant reiteration of that qualification; its significance will become more apparent in a moment) presents all its content more or less simultaneously. To a sighted user, everything on a page is pretty much equally available at all times.
Contrast this with the way in which a screen-reader presents a page; the difference is between seeing everything at once and hearing one piece at a time - between simultaneous access to all content and sequential access to the next piece of content. If a web-based application is being accessed through a screen-reader, the user is led through the page a piece at a time.
So here's the problem: under normal conditions, the user has immediate access to the fact that something's changed (be it by the motion of the page, color, or whatever) in virtue of her ability to perceive the page as a whole all at once. There doesn't seem to be a comparable way for a screen-reader user to get the same sort of immediate access to the fact of a change, given that her experience of the page is so much more constrained.
* I know next to nothing about screen-reader technology; perhaps there's a way to use voice tone, timbre, perceived location, or some other attribute to draw attention to the results of a dynamic process. Nevertheless, it seems like there's a huge can of worms here just asking to be opened...
4. January 30, 2004 09:13 AM
Menno Posted…
Do webapplications have to degrade?
Well, they don't have to of course, unless maybe you are by some law required to adhere to the 508 rules?
Section 508 requires that Federal agencies' electronic and information technology is accessible to people with disabilities. http://www.section508.gov/
Does this mean, for instance, that the intranet of the FBI has to be 508-compliant? I have no idea...
5. January 30, 2004 09:58 AM
Tim Posted…
My first question would be: do desktop applications degrade? If so, in what way(s)? The more dichotomous my professional life becomes (web-apps by day, personal or small-business public websites by night and weekends), the more I agree with Mark Wubben about webapps not needing to degrade, but websites needing to be accessible for everyone. However, I am not sure that "the line between the two is pretty clear". Or at least it isn't for anyone other than those who have to operate in both spaces everyday.
Web designers/devs constantly superimpose the principles of one space onto the other, and vice versa. Everyone, of course, is limited by their own experience, but I don't think a clear enough distinction exists among professionals. Why should Section 508 even address webapps? Because some of the technologies in each space overlap?
Users simply want more desktop app functionality in systems that are build using tools ill-suited for the job. They don't know (or care) that HTML was only ever meant to mark up text to represent a hypertext document for transmision over the network (which it does quite well). Nor do they care that the entire enterprise of trying to fit the "HTML/HTTP" square peg into an "interactive GUI" round hole means webapps (as they are currently implemented) can't hope to rival the level of interactivity of even the most hacked together desktop app.
What mechanisms does the average desktop app have to ensure accessibility for all? Those are the concepts and principles that should guide the design of a web-based app.
Parenthetically, I don't think Section 508 adequately addresses the issues of accessiblity regarding public websites either. Although well-intended, it's really a pitiful piece of legislation, but that's a separate discussion.
6. January 30, 2004 10:08 AM
Tim Posted…
As a brief follow-up to my comments, it would probably help to add that I currently work for a government agency that develops software (mostly web-based) for other government agencies (US). And I can say that even within our own organization, where this issue comes up almost every day, there just isn't consensus on how to handle this. And, by the way, I haven't done any work for the FBI, but they're /intranet/ is not required by law (although it is encouraged) to be 508 accessible. Section 508 covers /publicly accessible/ websites.
7. January 30, 2004 11:17 AM
Scott Partee Posted…
Once you're pinning yourself to a specific browser, you might as well develop a client.
8. January 30, 2004 03:23 PM
Amourti Posted…
On a related subject, why can’t we have screen readers that parse the html code of documents rather than reading it like printed page with links in it? Some do this partially, reading things such as bold and italic but not much else. Such screen readers could parse a webpage, with an alternative specialized CSS assigned to by the designer, based on an already easily accessible structure provided by HTML. With such screen-readers, webpage accessibility would be measured by how semantically correct its code is.9. January 30, 2004 05:40 PM
Darrel Posted…
A few observations:
- Accessibility is not a synonym with 'make sure it works in a screen reader'. Acecssibility is about making something more accessible to everyone.
- Just because you are using javascript does not mean you have to forgoe accessibility issues.
- I work for government. A lot of the software we purchase is far from accessible. Hell, it's far from being usable or even stable much of the time.
- Listen to Scott. He has a very good point. (Being that if you're depending heavily on browser-specific technologies and scripting that may cause accessibility issues, why bother with the browser at all? Just make your own thin client that takes full advantage of a custom interface.)
10. January 31, 2004 03:54 PM
Tim Posted…
I agree with Darrel's comments on accessibility and javascript. However, I don't agree with the last bullet point, or the original comment from Scott.
In response to what Scott wrote ("...you might as well develop a client"), and Darrel's response ("why bother with the browser at all?"). I agree, you might as well...except then you have to distribute said client, which is one of the biggest drawbacks to a client-server architecture. It can be extremely expensive in time and resources. If I'm not mistaken it's one of the biggest reasons this approach has been trumped in the last 8-10 yrs with web-based architectures.
When the "client" is already distributed, say in the form of a popular web browser, you no longer have many of the financial and logistical headaches of distributing a client to numerous desktops (often halfway around the world).
Another disadvantage of client-server was that it often tied one to a specific vendor. Again, the use of a browser (even in a nonaccessible way) affords more flexibility, as cross-browser approaches are more possible now than ever. So using a browser-based (vs. thin-client) approach can save an organization from a) having to purchase a product (inflexible) or b) building it from scratch (expensive). Without getting too far away from the original question, my point is that there are good reasons to "bother with a browser" over a thin client that have nothing to do with accessibility.
One thing I need some clarification on is what we mean when we say 'web application'. I don't mean that in an esoteric or overly-academic way. I mean are we talking more about amazon.com/ecommerce type applications, stuff behind a corporate firewall, XUL or plug-in type of things, web-based admin tools, customer facing, etc? Different criteria apply to each of these types of apps because they target different audiences. Section 508 doesn't (and in some cases shouldn't) apply to many of these.
George wrote: I mostly feel the problem is Section 508 does not address the domain space of Web-based applications at all.
A) I couldn't agree more, and b) I think in some cases that's the way it should be. I think it needs the most work in the area of amazon.com-type applications. To me this is clearly the application space where one sees a clear need to simulaneously address an audience with varying levels of impairment.
11. February 2, 2004 10:37 AM
Darrel Posted…
"It can be extremely expensive in time and resources."
Well, that's true of the browser as well. We were developing a site for a LARGE HMO once. They continually were getting errrors on all of their internal machines. We checked and rechecked the site in all flavors of IE on our machines, and they confirmed that they were running IE 5.5.
I finally had the IT manager read the exact version number of the IE they were using. It turns out they were using a BETA version of IE. Ugh. His reply "uh-oh, that's not good. We just standardized the entire campus on this version."
And with security patches being released for browsers all the time, I'm not sure if there is a huge difference between the distribution of the browser client or your own client.
"Another disadvantage of client-server was that it often tied one to a specific vendor. Again, the use of a browser (even in a nonaccessible way) affords more flexibility, as cross-browser approaches are more possible now than ever."
While I completely agree with that in theory, I rarely see it in the real world. Many 'enterprize level web based' systems I've seen typically require a very specific browser and much of it, while perhaps not proprietary, is so poorly put together that is is proprietary in its obfuscation.
I've seen (and have been forced to used) WAY to many IE6/PC-only 'web based' applications. The interface ends up being a gigantic mess of javascript functions that would have been much easier to develop quickly and efficiently in something like Visual Basic. (or, for the slightly more ambitious, make it fully cross-platform with Java).
P.S.: Why do I have to wrap everything in P tags, but I tags don't show up? (I'm not sure how to quote in here...)
12. February 2, 2004 10:45 AM
Nate Posted…
Darrel, apologies about the comment form here, it needs some work to be a little easier to use. I also need to add some info about posting options. Meanwhile, if you'd like to quote, you are welcome to wrap the quote around a blockquote tag.
This is what a blockquote sentence looks like. It should be used instead of a paragraph (p) tag. If you'd like to use italics, the emphasis tag (em) can be used.
In the near future I'll have more info about posting options linked near the comment entry form. Ok, now back to the interesting thread
13. February 2, 2004 11:35 AM
Bill Posted…
Tim said that section 508 applies only to publicly accessible websites. I hadn't realized that limitation on 508. I constantly preach the need for 508 compliance to internal US govt organizations and am typically ignored becuase that office/department whatever has no employees with specific accessibility concerns.
It seems to me, regardless of the initially targeted audience it is foolish to ignore accessability in any webapp especially when dealing with a government agency since they have more rules in place for enforcing diversity in the workplace and thus are, perhaps, more likely to hire someone in the future with accessability needs.
However, with that said I am as guilty as anyone else here of building web apps that aren't necessarily accessible, particularly to those using screen reader technology. (Dynamically adding rows to a table being an excellent case in point).
I had to develop a simple web-app for the american foundation for the blind and that was probably the most difficult experience I have been invovled with in regards to web development simply because no matter how hard I tried to fit into the 508 and W3C accessability standards the site still had usability problems for blind users. Luckilly, the customer (The AFB) was very patient and taught us far more about how they "Listen" to the screen reader than any of us could have ever guessed.
Interestingly enough, when complete, we had a javascript free app that ran fairly well, was as easy to use for us as it was for them. It was amazing really as they were able to browse through the pages far more quickly than we were - I don't know if that is the standard experience of blind websurfers but it seemed our customers were very attunded to skimming data when listening. Their screen readers read at such a fast rate it was very difficult for any of us to follow along with them at times.
Sorry for rambling but there is a point here. Any webapp can be well designed and usable by pretty much anyone with accesability issues. The tricky part, to me, isn't deciding if it should be done, but how to do it. Im not sure that is a question that can be answered stricly by people without accessability issues. The thing is there are alot of other accessability hurdles beyond vision that I have never even had to deal with and wouldn't even begin to understand a way to design for. My company is tiny and we don't have a research and development budget. Sadly, we basically only have the time and funding to learn how to deal with these different issues when someone with one of them is paying us.
Finally, in response to Menno, I don't think the user experience has to be the same across all user intefaces - however it should be usable across them all. I think that is the purpose of accessability standards and legislation and not some impossible level of exactness.
14. February 2, 2004 02:12 PM
Scott Partee (halfass.com) Posted…
I'd just like to clarify that I am largely in favor of migrating and developing applications (regardless of audience: internal, eCommerce, HR applications, whatever) on a "web" model. My point was simply that you may be no better off than had you developed a client if you are heavliy hooked into a specific version of a specific browser. In fact, you're really having unsafe app sex at that point. What happens if somebody clicks "Windows Update" and destroys your applications interface forever?
The original post, being about Accessibility and Web Applications (meaning, NOT a client), is still raising valid concerns and I don't mean to discount that. I agree that just about any app can be developed using web standards, but how to do that and to what level devices like "screen readers" should be supported is tricky business and one that will, for now, almost always be decided by "the business" in any big development project.
15. February 2, 2004 03:58 PM
Tim Posted…
First off, this is the single most useful discussion I've read or contributed to on this topic in a long time. So thanks for the posting.
Darrel wrote:
And with security patches being released for browsers all the time, I’m not sure if there is a huge difference between the distribution of the browser client or your own client.
Unless it's a wide range of browsers that are standards-based. Granted, this is /only now/ becoming a reality. I completely agree with the point that developing for a specific browser is in most cases no different than having a VB front-end, etc. (and in some cases worse, as Darrel points out). But I think situations like this make a case for moving toward a standards-based approach that would target a wider range of browsers. My point in the previous post was definately /not/ that it should be a /single/ browser (or platform), but that it's smarter to have it be a browser-based solution (versus thin-client) for reasons that have nothing to do with Section 508. The issue with the locked-into-IE6 scenario presented wasn't so much accessibility, but the fact that it wasn't cross-browser.
Some include the concept of targeting a wider variety of UAs (browsers, screen readers, PDAs, etc.) as part of an overall approach to accessible design, and indeed in a philosophical sense it should be! It's more than just "make it ok for screen readers" (again, good point Darrel). But to my knowledge, Section 508 makes no mention of this sort of thing specifically (which is why, among many other reasons) I'm so critical of it. In other words, it says nothing about Joe Q Public (who is not disabled) viewing whitehouse.gov on his portable device on the train. Many would say designing for this user scenario is a big part of accessible design. Well, in the Section508 sense, it isn't. Stretching the concept of accessibility to more generally mean 'inclusive-to-alot-of-devices' is a philosophical approach to design that has recently been embraced by Web Standards advocates (with which I wholeheartedly agree). I'm sure the 'spirit' of the Americans with Disabilities Act is 'inclusive', but it specifically applies to providing comparable access to government electronic resources to citizens with disabilities, which isn't Joe Q on the train. Even though it flies in the face of reason, it /is/ possible to have an accessible website that works on a limited number of devices. So just like is isn't just about "make it work in screen readers, it also isn't about "make it work in IE, Mozilla, and Safari" either. (although perhaps it should be).
Bill wrote:
Tim said that section 508 applies only to publicly accessible websites.
It's not that it /only/ applies to public websites. I wrote that in haste (and poorly). It applies to internal sites as well -- if such a need is present.
Section 508 says:
[Federal agencies will ensure] individuals with disabilities who are Federal employees to have access to and use of information and data that is comparable to the access to and use of the information and data by Federal employees who are not individuals with disabilities...
Since most people who are trying to implement these things aren't lawyers, this is interpreted a million different ways. Unfortunately, it's been my experience that it amounts to a 'how can we avoid a lawsuit' type of attitude whereby agencies ensure their corp website is '508-ready', and then run around seeing if anybody in the organization (some aren't large) has any special requirements to do there job, in which case they promptly provide 'comparable access' for the internal sites.
Bill wrote:
I constantly preach the need for 508 compliance to internal US govt organizations and am typically ignored because that office/department whatever has no employees with specific accessibility concerns.
This is the real shame, IMO. And it's what I was alluding to. But according to 508, if the agency is providing 'comparable access', they seem to be within the law. The problem is twofold: 1) Section 508 needs alot of work, and maybe more importantly, 2) the culture too often is one of avoiding a lawsuit, rather than simply taking the steps to make the content/app as widely available/usable as possible. So as far as I'm concerned, keep preaching! We need it. Although I can certainly envision situations that don't necessitate 508-style accessibility, they are IMO the exception, not the rule (particularly in govt).
Bill wrote:
I had to develop a simple web-app for the american foundation for the blind..... I'm not sure that is a question that can be answered stricly by people without accessability issues.
I think experiences like what you had with the AFB are the kinds we need to truly inform to issue. You're getting real feedback -- debunking myths, opening your eyes to things you hadn't considered, etc. We also need this sort of data about desktop applications (as I said before). The development of websites has garnered much of the attention that has resulted from the legislation. But at least the US legislation (can't speak to UK or others) actually uses the term 'electronic and information technology'. To me this includes much more than just websites/apps.
Correct me if I'm off here (or point to a good resource), but how usable is the MS Office suite (or any popular desktop app), for individuals with varying levels of motor, visual, or another type of impairment? I'm wouldn't expect the user experience to be /exactly/ the same, just acceptably usable. Is this out there?
16. February 2, 2004 04:32 PM
Bill Posted…
Tim Wrote:
Correct me if I’m off here (or point to a good resource), but how usable is the MS Office suite (or any popular desktop app), for individuals with varying levels of motor, visual, or another type of impairment? I’m wouldn’t expect the user experience to be /exactly/ the same, just acceptably usable. Is this out there?
I dont know how effortless the user experience is in products like MS Office for the visually impaired, however I do know it is at least usauble between a screen reader and super enlarged fonts for a teenaged boy I know who is considered legally blind but still has some usage of his eyes left.
Time Wrote:
I think experiences like what you had with the AFB are the kinds we need to truly inform to issue. You’re getting real feedback — debunking myths, opening your eyes to things you hadn’t considered, etc. We also need this sort of data about desktop applications (as I said before).
I agree that the experience was a critical one. However, as is the case with many projects for external customers it can oft be difficult to get any constructive feedback on the overall usability of the site. It seems many customers get caught up in color choices more so than functional or usable design. Based on my one experience I feel I developed a far greater appreciation for what to do to help make a site more accesible in the spirit of 508 however I know I still have long way to go to truly make any site completely accessible.
How many of you have had the opportunity, when working on a project, to truly investigate the accessability of your work. Furhtermore, have there been any "tips" you picked up beyond "make your stuff standards compliant" that help you in your design to at least achieve basic accessability?
17. February 2, 2004 08:01 PM
Chris Vincent Posted…
I would have to agree completely. The "rules" we have seem to ignore certain things that web apps need to do. For example, a web app is almost impossible to bring to AAA compliance due to the fact that you aren't allowed to have form fields with that are initially blank, because some browsers won't render the fields at all. This is a situation in which I think the accessibility issue is with the user agent, not the site itself.
Part of the reason that the accessibility guidelines (508 and AAA) are giving web app developers problems is the fact that they weren't designed with interactivity in mind. They were designed for pure content pages. They assume that the page presents content and that the user will read it. The fact that some web pages are built for more than just reading is where the accessibility rules fail.
In my experience, I just try my best to make the app accessible without making it less usable for the unimpaired. Guidelines are just guidelines, after all.
18. February 3, 2004 04:13 PM
Niket Posted…
Accessible doesn't mean that all people will have the luxury of using the extra layers of style/behavior. As long as the informtaion is available, its accessible. For example, an alternative version could be created... just like BBC has a text-only version.
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-alt-pages
Menno Posted…
As far as I'm concerned just having all essential content (easily) accessible by stuff like screen readers, handhelds, text browsers, etc. is already a very good scenario. All (client-side) interaction mechanisms that helps you find, organize and work with this content is (realisticly) not reproducable in these environments.
Typically, web apps rely heavily on these mechanisms to make life easier and the tool more productive. I'm not sure what 508 says on this, but it would be ridiculous to expect the complete user experience to be the same across different browsers, let alone different devices.
That said, I do believe it is the responsibility of the designers and programmers to make sure that all of the sophisticated stuff degrades nicely.