- From: Giorgio Brajnik <giorgio.brajnik@gmail.com>
- Date: Wed, 27 Jul 2005 15:58:15 +0200
- To: Phill Jenkins <pjenkins@us.ibm.com>
- Cc: "Roberto Scano (IWA/HWG)" <rscano@iwa-italy.org>, gv@trace.wisc.edu, w3c-wai-au@w3.org
[Phill, in case this message does not go to the list, could you forward it for me please?] I don't think invalid code is a major accessibility issue, and therefore that it should NOT be a level 1 requirement to have valid code. I think that the lack of an appropriate definition of accessibility that is linked to testing methods and criteria, prevents us from being able to clearly define in guidelines what an accessibility barrier is, and what are its negative consequences (like impact on end users). Defining accessibility as "possibility for everyone to access content / use authoring tools for generate contents" is, I think, too general to be operable. "Usability for disabled people" is more practical because it inherits from the def. of usability appropriate contextual aspects that make it more operational. Eg. one def. of usability says (approximately) "... effectiveness, productivity and satisfaction for GIVEN users, in GIVEN operational situations, while aiming at GIVEN goals". On the one hand the focus on effectiveness, productivity and satisfaction allows one to think of users performance criteria (eg. we look how a sample of users behave when put in front of a web site; and from observations we derive metrics that are associated to those 3 criteria, like number of errors that is associated to effectiveness). This is good because accessibility encompasses human perception and cognitive processes. On the other hand the def. makes explicit 3 important contextual factors: Who we're dealing with, What they should be doing and Where/When/How. This allows one to say (and test) for example that blind users using JAWS v.3.5 on IE 5.5 cannot (or can) subscribe to a newsletter. Both the contextualization and the focus on user performance criteria are missing or not clear enough with some currently used definitions of accessibility. If they were, it would be easier to understand if invalid html code is or not an accessibility issue, and to what extent (meaning "what kind of negative impact it has on which kind of user in which kind of situation wrt a certain goal"). For example, Slatin's and Rush' definition (with an accessible web site disabled users can achieve the same goals as non-disabled people) is quite operational. If we were to use that definition, the code validity issue could be investigated by finding cases where an invalid page prevented disabled users to achieve something that other ones were able to. I think we could try to deepen this issue, at least by finding out concrete cases where some AT failed to function properly to such an extent that the violation would be associated to a level 1 violation. While I agree with all has been said about why a valid page is a good thing, in my experience I've seen only one case where invalid code prevented a user of a non-recent version of JAWS to perceive (and therefore understand and use) a home page of a site. The main problem was the inability to handle different frames, which made the user unable to skip onto other frames of the (framed) page. Other usages of screen readers, magnifiers, transcoders, PDAs, textual browsers on real web pages did not show this kind of problem (for the users I did accessibility testing with). My best, -- Giorgio Brajnik ______________________________________________________________________ Dip. di Matematica e Informatica | voice: +39 (0432) 55.8445 Università di Udine | fax: +39 (0432) 55.8499 Via delle Scienze, 206 | email: giorgio@dimi.uniud.it Loc. Rizzi -- 33100 Udine -- ITALY | http://www.dimi.uniud.it/giorgio On 7/25/05, Phill Jenkins <pjenkins@us.ibm.com> wrote: > > Valid code is NOT a disability issue. > If a piece of software doesn't compile, it's not a disability issue. If a > piece of hardware is physically broken, is not a disability issue. I > believe we need to keep the definition of accessibility to only deal with > disabilities. If not, we'll go crazy adding all the other prerequisites; > such as: Is there electricity? Are there phone lines to access the > internet?, Is there a working computer? Is everything bug free? etc.etc. > > I believe the code should be valid, just not that that should be in an > accessibility checklist for Authoring tool developers. They have other > checklist for that stuff - lets not loose credibility with them... > > Regards, > Phill Jenkins > IBM Worldwide Accessibility Center >
Received on Wednesday, 27 July 2005 16:05:36 UTC