What do you want to know about accessibility and web apps?

As I mentioned to you on Twitter, I'd love to see a demonstration of some common sites as they're being read by a screen reader. If you can include examples of good ones AND bad ones, that'd be great.

I think that a lot of web devs will feel much differently about accessibility once they hear the painful experience of a screen reader going through a poorly marked-up site.

This. Also if you know exactly what we should look for when writing mark up? I feel as if a lot of common knowledge on this topic is on the same level as SEO optimization - a bunch of mumbo jumbo and nobody really knowing what they're talking about. This should change.

If you really want to drive change, do this:

- Create a very convincing, clearly written and illustrated report on the top 100 visited websites (Amazon, Facebook, etc.) and how they fail on accessibility.

- Film yourself and your daughter struggling with these sites (burn to DVD).

- Contact well known film directors you think might do a documentary on people with disabilities and send them the video and report. Contacting enough people will make a difference.

- Getting a half-hour spot or so on a major U.S. television network wouldn't be too shabby either, so try to make connections there.

- Contact and work with the politicians and others updating the ADA, but be wary of big talk and no results. There is a lot of lobbying power from a lot of industries that don't want to have to spend the money to make their sites and software accessible.

Other than that, I side with the guys that say that as long as providing accessibility is not enforced and there is little or negative financial incentive, it just won't happen. Which is sad.

Very few places I've worked and done web-related and web development for have cared much if any about accessibility. Any effort I put into making a site more accessible was not met with any praise, and usually I felt as if people thought I was wasting effort.

My heart goes out to you and your daughter.

That would be wonderful.

I would love to see a list of the simple things to do that are more or less trivial from a developer's perspective, but have a vast improvement on a disabled person's ability to use a website (alt tags on images is one that comes to mind). Especially if you were somehow able to demonstrate the improvement it makes for you (some kind of before/after thing would be great). I think most devs don't realize how hard it is for people with disabilities to use their sites.

Nice timing on exploring this topic. The DoJ just finished a round of title III revisions to the ADA, they've been exploring expanding the mandate for accessibility to more websites. (If anyone has a good analysis of the final rules wrt the web, I'd appreciate a pointer. I'm under the impression that any changes aren't very broad-reaching.)

"The Department has consistently interpreted the ADA to cover Web sites that are operated by public accommodations and stated that such sites must provide their services in an accessible manner or provide an accessible alternative to the Web site that is available 24 hours a day, seven days a week. The final rule, therefore, does not impose any new obligation in this area. [...] The Department intends to engage in additional rulemaking in the near future addressing accessibility in these areas and others, including next generation 9-1-1 and accessibility of Web sites operated by covered public entities and public accommodations." (fedreg pp56236-56285)

They use an example of online ticket purchasing as a common hardship. (eg by losing timely access to popular events due to the need to use another method to purchase the tickets.)

Sounds like a great idea!

1) I'd love to hear about the different issues people have and what tools they use to overcome their problems. Seems like this would help give everyone a level playing field to start talking about developing for accessibility.

2) I've always had trouble with the "build it however now and we'll make it accessible later" approach. Unobtrusiveness needs to come first, Ajaxifying later. However, it's hard to sell that when you don't have much time to begin with. Perhaps you could speak to how we, as developers, could convince our clients (and fellow team members) that accessibility is a) so damn important and b) not just for blind people.

3) I'd also love to read how to make unobtrusive, accessible development work on a team. Do you develop the whole thing with no Javascript first, then come back around and hit it with Ajax? Can you do both at the same time? How would non-technical testers determine it's working properly?

Just some thoughts. It's a great idea and I can't wait to see what you come up with! Keep fighting the good fight Brian!

When I first started writing web apps in 2004, I tried to make everything nice and accessible. CSS, semantic HTML, etc. However, it was a huge pain in the ass.

So now, for my b2b startup, we ignore that. We move quickly and try to push the product out the door so we can succeed. One of the things that has fallen by the wayside is accessibility. Further, with 15 different balls to juggle, I just can't make myself care about the percentage of users who can't use our site.

For my startup, it seems that we would have a negative ROI for making our site accessible. In fact, I suspect the only way to get people to build better sites is for the money to clearly be worth it.

So my question is this: why should a startup invest effort into something that will only affect a small number of users? Similarly, we don't test our site for IE6, just because it's a pain.

I understand how you feel. I've worked for startups that felt that way. If you've decided it's not worth it to focus on accessibility, I doubt I can change your mind with a few words on this HN post, especially if you can't make yourself care about a potential customer base. But I'll try anyway.

If I want to start a restaurant, part of the cost of doing so is ensuring that the facilities I provide are accessible to the disabled. I need to have menus for the blind, or at least provide reasonable alternatives. That costs me money, and doesn't have a good ROI. But it's the law so I do it.

Of course, there's no law mandating that your web site needs to be accessible, even though Target has been sued and settled out of court for having an inaccessible web site, as have a few others. If you plan to sell your services to a school or university that takes federal funds, then there are in fact laws that affect you.

I'd argue it's not much of an additional cost to implement if you do it from the beginning, but it is certainly hard if you have no background or idea how to start. Things are different than they were in 2004, although we have a different set of issues to deal with.

One thing I hate though is when people say "X is easy if you know how it works", so I'll do my best to explain some of these concepts as I go forward. Just promise you'll follow what I'm doing and keep providing those devil's advocate responses. Deal?

An update of http://diveintoaccessibility.org would be interesting - this was my start when building quippd, but I'd definitely like to know if there is more that Mark is missing.

Like I mentioned on Twitter, its really all the little things (like how annoying vertical bars to someone listening to it) that have been helpful. Looking forward to your articles.

I admit I haven't done any research on it, but I've always assumed that it's a pretty easy problem if you're talking about relatively static content-driven pages, but I've always assumed that when it comes to highly interactive web apps it becomes very difficult or even borderline intractable. Is that true? Are you able to use a site like, say, pivotaltracker? And if not, how would you get it to work?

Pivotal Tracker is one of my favorite apps as a developer, but it is a great example of a site that has a very unfriendly interface for low vision users. There are no functions on PT that require javaScript. The interface is great because it uses JS and AJAX, but it could have been built from the ground up using straight requests and redirects for its features, and then easily wired up with JS.

When we build apps for section 508 compliance, we build them without JS and then add it in later to improve the UI for end users. I'll be talking about this a lot.

Our application is used by a lot of seniors. So I'm interested in this topic.

I received an email last week from a 70 yr old lady who was using our software. Not the typical web-app user base.

Outside of trying to close the big knowledge/generation gap when I design for these users, I'm starting to look at accessibility problems, since they are likely more prevalent with seniors.

My dad used to teach kids with disabilities. He always used to tell the other teachers that the disabled is a club anyone can join at any time, without notice.

At work we sometimes use asp:Label instead of just putting out the text since with labels we can get a tooltip. We typically use this in table cells to present only 20 chars of a string, and have the full string as a tooltip(alt="the tooltip").

The label doesn't have a "for" attribute.

I wonder how those tools blind use are affected by this. Do you happen to know?

if the label wraps the form field it's associated with, you should be ok. However, the "alt" attribute is completely inappropriate for tooltips. If you're looking to do something like that you should provide real tooltip functionality either using the title attribute, or better, display text right next to the field that's visible, which you turn into tooltips when JS is enabled. Then everyone wins.

From HTML4's spec:

"The alt attribute specifies alternate text that is rendered when the image cannot be displayed (see below for information on how to specify alternate text ). User agents must render alternate text when they cannot support images, they cannot support a certain image type or when they are configured not to display images."

I checked the actual HTML generated by the asp:Label control.

When no control is associated with the label, the control renders into a span element and uses a title attribute on the span to create the tooltip.

Is this still a problem for accessability software?

I'd check it with a screenreader. Freedom Scientific gives you a 45 minute demo of JAWS. After 45 minutes, it doesn't work until you reboot your computer. Kinda nice for testing sites.

Thank you for the answers.

Would you be able to comment on this website? http://www.looktel.com since it's important for us to target the visually impaired but wanted to get some outside validation to see if we designed and implemented the site in the right way for situations just like this.

I can take a quick look, but you may want to contact me privately if you'd like a serious review.

The only thing that really stands out is the video. There's no transcript for the video or any real narration. It's a wonderful product, and the video does a great job of explaining to a person who can see well what the product will do, but I'm afraid that your target audience might not get as much out of it.

I'd recommend adding some descriptive narration to the video.

OT: I'm excited for the product. When can I try this out for myself? Soon? Please? :)

You bring up an excellent point here Brian! I'd love to hear other things like this that aren't really development issues per se (no amount of unobtrusiveness will get us video transcripts). Are there other non-development issues we should keep in mind?

I'd like to know how to make an ajax web app accessible.

If something changes you can change a background color on an element for a visual user. Is there something similar you can do for someone using a screener reader.

Screen readers are only part of the problem. A colorblind user might not even notice that something changed. :)

I'll definitely cover some tips on how this works. I have a chapter in http://www.pragpub.com/titles/bhh5/ that shows how to use HTML5's ARIA support to alert the user to feedback.

(edited - fixed link)

I have a medical handicap and two special needs sons. I got a job about 4 years ago. My first full-time paid job. Almost everyone at work that I have talked to for any length of time has some kind of medical problem. Some of the ones I know of at the company I work for:

  Quadraplegia
  MS
  Fibromyalgia
  Cancer
  High blood pressure
  High cholesterol
  Diabetes
  Asthma
  Allergies
  Insomnia

I have to manage my condition and finally getting a diagnosis late in life was very empowering in that regard. Based on some of the comments here (and general life experience), one of the things you might do well to address is that a) most folks have some kind of limitation, even if they don't self-identify as "the disabled" and b) accessibility = ease of use, and that = both larger potential user base and likely higher traction.

I don't know much about web design, but the target market for two of my websites is people who tend to have both physical limitations and financial limitations (rooted in their physical limitations, which can be expensive and also inhibit earning capacity). Those financial limitations frequently translate into hardware and software limitations. So I keep those issues in mind when thinking about what to do with my sites.

Good luck with this. It's important stuff.

Well said and exactly the message I hope to spread with this. At the end of the day accessibility means accessible to all.

Or, more succinctly than my earlier post:

Accessible means "people-friendly".

Again: Best of luck with this.