@Peter Title of my article is 'Accessibility does not matter?' (the question mark is very intentional there).
To address your second point I will go back to the app I am currently developing. It needs a lot of JavaScript to improve usability of the tool and a progressively enhanced solution would be so far from the JavaScript solution that in reality they are like 2 different implementations of the tool. Considering this tool has already taken me 10 solid days of coding (in my spare time) without following the full progressive enhancement route and I have another 20 days solid left in order to finish the Alpha version, while I cannot envisage this tool being used by a person with a non-JS support browser. Why should I spend time coding a progressively enhanced solution for this when I don't see this tool ever being used by a disabled person of any sort? Just to clarify, the tool will work perfectly with JS on, while it will still work without JS on, but the experience will be very poor in my estimation (so it would still be possible to use it, but a blind person would not enjoy using this at all I would say). On Sun, Jan 31, 2010 at 1:35 AM, Peter Mount <i...@petermount.com> wrote: > Jason your subject line is "Accessibility does not matter!". If you're going > to make a statement like that then I suggest you make a list of real world > examples to back up your claim. > > Plus how can an app be useable if some people don't find it accessible? That > is the flaw in your argument and it is a huge flaw. You are implying that an > app can achieve greater usability by using features which in turn deny > access to those users who can't use those features. How does this increased > "usability" benefit those people who can't use it? > > -- > Peter Mount > Web Development for Business > Mobile: 0411 276602 > i...@petermount.com > http://www.petermount.com > > On 31/01/2010, at 12:16 PM, Jason Grant wrote: > >> @Thierry >> I don't see how breaking a wrist has much to do with accessibility? >> My article does not say 'break all accessibility rules' if you can. >> It basically tries to say that a given advanced app solution (such as >> Google Calendar) requires JavaScript support to work in a >> semi-meaningful way. >> This fact usually impacts users accessing the site/app with some sort >> of an assistive technology or a technology with shitty JavaScript >> support (I used BlackBerry Bold 9000 as an example of common tool used >> to access the app I am currently working on). >> >> From UXD point of view we want to provide target users with highest >> level of usability through devices they are using. That way we >> increase profit and ROI. >> >> Under WCAG1.0 we would be coding for 'universal accessibility' and >> maybe degrade overall usability of the solution, while not providing >> optimal support for BlackBerry (as a scenario). This is all to do with >> lack of resources (time, money, skills, etc.). >> >> My argument is that 'high selective accessibility' is better than >> 'regular universal accessibility' if that sum-up makes any sense. >> >> This is all driven by the nature of highly varied user agents on the >> market now, compared to what was the case some 5 years ago even. >> >> Hope this makes sense. >> >> So I am by no means against as high accessibility as possible, but I >> think that evaluation of 'high accessibility' needs to be approached >> from a clever, business angle. >> >> On Sun, Jan 31, 2010 at 1:03 AM, Thierry Koblentz >> <thierry.koble...@gmail.com> wrote: >>>> From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] >>>> On Behalf Of Jason Grant >>>> Sent: Saturday, January 30, 2010 2:14 PM >>>> To: wsg@webstandardsgroup.org >>>> Subject: Re: [WSG] Accessibility does not matter! >>> >>>>>> So, what are you getting at? Yes, let's make the intranet completely >>>>>> inaccessible and just wait until an employee with disabilities gets >>>>>> hired, then redo it all? >>> >>>>> Also, an employee with no disability today could have one tomorrow. >>> >>>> @Thierry Koblentz >>>> 'Could' is not something we should be developing for. We need to know >>>> who we are developing for, >>> >>> As I suggested in my post, ignoring accessibility pretending you know your >>> audience is a mistake. Because any user can become disabled one way or the >>> other (because of a broken wrist for example). >>> >>>> otherwise it's a bit of a hit and miss. >>> >>> I'd say narrowing your target audience increases your chances of missing. >>> >>> >>> -- >>> Regards, >>> Thierry | www.tjkdesign.com >>> >>> >>> >>> >>> >>> >>> ******************************************************************* >>> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >>> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >>> Help: memberh...@webstandardsgroup.org >>> ******************************************************************* >>> >>> >> >> >> >> -- >> Jason Grant BSc, MSc >> CEO, Flexewebs Ltd. >> www.flexewebs.com >> ja...@flexewebs.com >> +44 (0)7748 591 770 >> Company no.: 5587469 >> >> www.flexewebs.com/semantix >> www.twitter.com/flexewebs >> www.linkedin.com/in/flexewebs >> >> >> ******************************************************************* >> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> Help: memberh...@webstandardsgroup.org >> ******************************************************************* >> > > > > ******************************************************************* > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > ******************************************************************* > > -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
