Sunday, March 22nd, 2009 - 1:13pm
When is the right time for accessibility?
Before I start, I need to declare a few things:
- I believe that accessibility helps us to innovate and create.
- I believe that accessibility is something that must be provided.
- I believe that accessibility is different than interoperability.
- I believe that accessibility is not a hindrance to progress.
There is much kerfuffle over Bespin, a <canvas> based tool that was put out by Mozilla Labs. (Incidentally, I’m really hoping it is Bespin as an homage to Star Wars’ Bespin and not BeSpin, as in the conjoining of the two words “be” and “spin”)
Many people are crying foul saying that <canvas> is inherently inaccessible at this point, and therefore the accessibility problem must be solved before the launch of the product/project. This fits perfectly well with the notion that technologies/projects/products need to be accessible from the get go. Generally, I support this sentiment.
Reading the emails, blog posts and twitter reactions has me questioning one particular aspect of this accessibility challenge. The question is not whether or not a technology should be made accessible, but when?
Accessibility Investment
Many individuals and organizations take accessibility very seriously and invest a lot of time and effort into making their work accessible. These efforts and investment are not to be taken lightly; they are precious and should be undertaken wisely.
As an example, when faced with issues of limited budget, time and prioritization, we’ll often suggest that organizations ensure that when JavaScript is on, their applications work properly with assistive technology rather than ensuring that their applications work with both JavaScript on and off. JavaScript on/off is an issue of interoperability — if your app doesn’t work with JavaScript off it sucks for people with or without a disability. Interoperability is best practice, but it doesn’t discriminate based on disability.
So, given that significant investment needs to be made in accessibility in terms of time, effort and money, when is the appropriate time to make that investment?
Consider a couple of scenarios:
- in dealing with an experimental technology such as Bespin, we don’t know if anyone is going to use it, let alone people with disabilities. What if it sucks for everyone? is there any reason to make that suckiness accessible to everyone?
- in addition to not knowing if anyone will use it, we don’t necessarily know how they will use it. Accessibility is part of user experience. Simply providing an alternative may provide a basic level of technical accessibility but may be unusable by people with disabilities. I would suggest that it is at least possible that until we know how people are going to use something, we have no idea with the most appropriate alternative will be.
Other emerging technologies such as AIR and Silverlight did not address accessibility in their 1.0 release of their product. Should they have? What if the technology was fundamentally unusable? What if, after 1.0, they looked at the product and said “this stinks, we have to start over.” Would it have been worth the investment in accessibility for a product/project/platform that died on the vine?
Accessibility in Mind and Implementation
Is it possible to include accessibility support “too early?” I’m not saying it should be an add-on at the end of the process/project/product development cycle, but I’m very seriously wondering what the optimal time for integrating an actual accessibility implementation is? Is it enough to keep accessibility architecture in mind from the beginning, but not implement right away? Should we get the basics right first, and then build in accessibility support based on that previously envisioned architecture after we know we have a viable product? We continue to say that accessibility should happen throughout rather than just at the end, but would it actually be better if we left it out, just for a little while, at the beginning?
Is it a better “business decision” to say very early on “we are committed to making this accessible, but we know we’ll fall short of the mark on our first cut; we want to get this right for everyone, and will, but in order to make it accessible, we need to get this out into the real world to see how people will use it, what they want from it, and then build in accessibility appropriately.”
My feeling — at least right now — is that our job is to ensure that accessibility and accessibility architecture is kept in mind from the outset of a project/product/technological exploration, but not necessarily implemented at the outset.
I’m just throwing these thoughts out there for discussion — there is nothing definitive in here, other than the fact that I don’t think there is going to be one correct answer for this. What do you think?
feather
March 22, 2009
Consolidating my thoughts on emerging technologies and accessibility implementations: http://bit.ly/146Ypa Would love to hear your thoughts
This comment was originally posted on Twitter
efa_tagung
March 22, 2009
When is the right time for accessibility? http://tinyurl.com/d7gbov
This comment was originally posted on Twitter
yatil
March 22, 2009
When is the right time for accessibility? http://tinyurl.com/d7gbov (via @efa_tagung)
This comment was originally posted on Twitter
Gez
March 22, 2009
Great article, and I think we’re mostly in agreement. The accessibility architecture is as important as any other aspect of a technology, so should really be there from the outset to get feedback on how a technology can be made accessible. Silverlight 1.0 had poorly documented (and undocumented) accessibility provisions. The result was that no one implemented accessibility in Silverlight 1.0, and the only accessibility related feedback Microsoft received was that Silverlight 1.0 is not accessible. The implementation needn’t be complete, but at least be capable of getting some feedback on how it could work.
gezlemon
March 22, 2009
Great article by @feather on when is the right time to provide accessibility provisions: http://tinyurl.com/d7gbov
This comment was originally posted on Twitter
stcaccess
March 22, 2009
Comment on @feather’s consolidated thoughts re: emerging technologies & accessibility implementations @ http://bit.ly/146Ypa
This comment was originally posted on Twitter
webaxe
March 22, 2009
When is the right time for accessibility? @feather http://tinyurl.com/d7gbov
This comment was originally posted on Twitter
Smiffy
March 22, 2009
Thanks for this Derek, and getting things in perspective.
My 0.02AUD worth:
I have never been involved in anything “big”, such as a new technology that is going to be used by many people. My thoughts are on how a web application would be designed/deployed but could nevertheless apply to more far-reaching technologies.
Once a very rough list of features/functions has been drawn up, then is the time that I feel that we should start the accessibility process. Go through each item on the list, work out if it CAN be made accessible before beginning any work on it. If the item cannot be made accessible, can it be replaced with something that can? Should that item have been included in the first place?
Only after this appraisal would I say that that development should go ahead. So, accessibility isn’t coming in at the beginning, but at a very early stage. If the Real World has already had a taste of this before accessibility work is undertaken, it is WAY too late in my opinion. Something to do with horses and stable doors.
Ricky Onsman
March 22, 2009
Good questions, Derek.
My feeling is that it is very useful to have an informed awareness of accessibility issues when developing pretty well anything, but this should not hamper the development process.
If everyone went in with the need for accessibility as part of the development mindset, it’s a) not so necessary to focus on accessibility exclusively and b) easier to deal with it once the project is in a position to deal with accessibility issues.
BUT – I feel this will only work if accessibility is part of the originating mindset. That way it’s not tacked on, but also not front of the queue.
catherine
March 22, 2009
Derek, I think yours is a dangerous proposition.
If accessibility, though kept in mind, is not actualised to the fullest possible from the onset, I wonder then who gets to decide if and when it is time to let people with disabilities in on a technology.
From what I can gather from your scenario, it would seem that persons with disabilities would not get to even be a part of that decision since before it can be ascertained when and whether it is “the appropriate time to make that investment” in accessibility, “we need to get this out into the real world to see how people will use it, what they want from it”.
Am I to understand that people with disabilities do not fall into this category of “people” ? That our user experience, what we want from it, is not as valuable ? That we have to wait for everybody else to have their turn before we get to know if we can have a go ?
icaaq
March 23, 2009
@feather ’s thoughts on when to start thinking of accessibility http://tinyurl.com/d7gbov (via @gezlemon) btw: @feather I love the design :)
This comment was originally posted on Twitter
Michal Migurski
March 23, 2009
Catherine, I’m going to pretend, as you do, that people with disabilities don’t develop software.
Derek’s argument seems to be primarily about prioritizing development costs, so there are two answers to your comment. It’s critical to get *someone* using a new technology in order to observe its use, and in most cases that’s a significantly smaller group than simply people without disabilities: it’s people known to the developer, people with the patience to deal with alpha software, people who can install software before it’s packaged into a one-click distribution, and people with the specific environment supported by the developer before porting to other platforms or environments. I’m looking at Bespin right now and it’s telling me I need to upgrade my browser before I can use it – I guess I’m not “people” either!
The second answer is that for a lot of open source projects, it really is up to specific user communities to adapt that software to their own platforms and needs, which includes people with disabilities alongside mac users, arabic speakers, and others whose unique situation is out of reach for the original developer. Open source is a social arrangement that makes it possible for groups with specific needs to actively involve themselves in the development of a piece of technology, and shape it as they see fit by taking on the costs of adaptation themselves.
I guess the bottom line is that yes, in fact it is true that generally speaking, people who are outside the development and marketing process don’t get to be part of the decision about specific investment priorities.
Laura
March 23, 2009
When is the right time for accessibility?
The time is now. The HTML5 spec is being written now. Later will be too late. It needs community thought, innovation, and action. It needs participation from not only impementors but users, authors, and developers.
Sam Ruby HTML time line called for outreach:
http://intertwingly.net/stories/2009/03/13/html5-evolution.html
How to join HTMLWG:
http://www.w3.org/html/wg/#join
kazuhito
March 23, 2009
When is the right time for accessibility? » box of chocolates http://ff.im/-1FYWM
This comment was originally posted on Twitter
David Bolter
March 23, 2009
Thanks for thinking openly in public. My thinking, as someone who also works in accessibility, is that to move society forward we need people to be honest and open. Part of this is not being afraid. I think ideally we should allow developers, who may or may not understand how to design accessibility into software, the comfort of releasing their product in order to get feedback, perhaps even directly pinging the accessibility community, without fear of attack. I believe we can’t afford to be oppositional.
Aside: I happen to believe that once front end developers understand what it means to design in accessibility, the architecture will tend to be more robust, extensible, testable, and maintainable. I think the longer the wait before accessibility (or inclusive/universal design) impacts the architecture, the less likely the latter is true.
Finally, I am open to different takes on all this. People should also feel free to be oppositional, or to cry foul, and to voice their concerns. It is really about what one thinks will move things forward.
Cameron Adams
March 23, 2009
It’s an opinion I’ve held for a long time, Derek — in order to innovate you have to prioritise. It’s not about cutting people out, it’s about including people as fast as possible.
If innovators have to wait till their product is accessible, it simply means they release two/six/eighteen months later. That’s more months they have to wait to figure out their product sucks or rocks.
Definitely you shouldn’t release a *final* version of a product that’s inaccessible, but you have to draw the line somewhere and say “this is what we’re throwing out into the world. Is it useful? How are you going to use it?”.
The danger you have to watch out for is using “innovation” as an excuse to not use best practices.
laura_carlson
March 23, 2009
@feather Time is now. HTML5 spec being written now. Later too late. Need collaboration innovation action http://bit.ly/146Ypa #accessibility
This comment was originally posted on Twitter
tessieteoh
March 23, 2009
http://tinyurl.com/d7gbov This is a great web accessibility article worth reading! Excellent point about javascript and that it’s more ab…
This comment was originally posted on Twitter
Matthew Pennell
March 24, 2009
Just as an aside: Bespin is programming in the cloud, thus the Star Wars “Cloud City” metaphor. :)
schaedelio
March 24, 2009
Reading ‘thoughts on emerging technologies and accessibility implementations’ by @feather http://bit.ly/146Ypa
This comment was originally posted on Twitter
Isofarro
March 24, 2009
Hi Derek, I think you’ve nailed the core of the argument well. There are experiments and then there are real products. Real products must be accessible if they are for public use.
I think that at the point where something goes from being an experiment to the point of it becoming a real product that’s where accessibility does need to be a deliverable. Bespin isn’t at that point, its nothing more than a proof-of-concept of using canvas as the basis of an application.
When Bespin becomes a service, people use it as an editor for writing code, rather than just seeing how cool it is, then accessibility should be a requirement.
The work required to get from an experiment to a real product is probably going to be too much for a number of projects, but that’s the point. If it isn’t feasible for it to be a real product because, for example, it can’t be accessible to the audience it is aimed at, then it’s perhaps the right decision for it to be nothing more than experimental. Maybe someone with better skill and insight can take that experiment themselves and use that as a demonstration for building it accessibly.
So I agree, experimenters need room to experiment and innovate. But real products need to be accessible.
What we don’t want to encourage is the continuing accessibility failure of Flex and AIR. That is just irresponsible, and I am hoping the Bespin guys won’t be making the same mistake when it comes to turning their concept into a real product or service.
Richard Morton
March 24, 2009
Why is it assumed that these sorts of discussions are just about web accessibility. It is great to debate this but I think we should also be demanding that all computer technology should be accessible. How accessible is Microsoft Office for example?
feather
March 24, 2009
Richard — yes, everything should be accessible. I didn’t limit this to just the web, we just happen to be talking about web specific technologies now. Incidentally, Microsoft Office is quite accessible, given the right tools, etc.
kunter ilalan
March 24, 2009
given the right tools :)
This article is again an exemplary one; thank you for making it accessible to us – so we could stea.. sorry, spread the word.
bests,
kunter
AlastairC
March 24, 2009
Hi Derek,
You make a good point, and I certainly wouldn’t vilify or make snide comments about a beta product that isn’t 100% in terms of accessibility.
However, ‘keeping it in mind’ is a little vague, and I can see people looking at a spec and saying, ‘well, we thought about it’.
Later down the line, because they weren’t aware of the implications, it’s too late to reverse or alter some of the fundamental decisions.
The mind it’s kept in is fairly important in that early stage, one with experience in accessibility will see things differently…
franklyRichmond
March 25, 2009
http://tinyurl.com/d7gbov
This comment was originally posted on Twitter
zibin
April 16, 2009
Which part of Bespin is not accessible?
Are you talking about the Canvas part where text are not rendered as text?
If that’s the case, another issue would be that the text are not cut-and-paste-ssable. So I guess this is a very “main stream” accessibility issue.
In any case, Bespin’s a good experiment.
Maria
May 7, 2009
What if a website rocks for disabled and less for the rest of the user community? Whould you give this the same importance?
ctford
June 9, 2009
I think you’ve overlooked that accessibility generates ROI beyond simply allowing more people to access your site.
Using progressive enhancement will improve your SEO and help your development process by allowing you to build and test your interaction seperately to your content/presentation. You’ll get more benefit from this if you do it from the start.