------------------------------------------------------------------------ Date: Mon, 18 Apr 2005 13:58:23 +0200 From: Thomas Baker To: DCMI Usage Board back-channel Subject: Accessibility - new proposal ------------------------------------------------------------------------ Liddy has reacted to the digest of our discussions (see my summary below). My gut feeling is that the best we can do, under the circumstances, is to finalize something rather close to what we "approved" in Shanghai. I propose: Definition: A description of the resource in terms of how it can be perceived, understood, or interacted with by users. Comment: An accessibility description might be used to match the (digital or physical) resource to a user on the basis of the user's ability profile. Implementers wishing to express the values for this element in a machine-readable language should consider treating such expressions as "related descriptions" in terms of the DCMI Abstract Model. In a nutshell: -- The definition returns to "description" (instead of "statement") -- but dc:description itself can have a literal value. -- It is not limited to digital resources (and Liddy agrees; see below). -- It does not cite EARL, which is not yet stable (and Charles agrees; see below). -- It includes a caveat with regard to associating the element with a "related description". -- It refers to the intended use ("matching"). As we did in fact "approve" such language in Shanghai, it would be awkward to argue that we have since changed our mind... How to proceed? Liddy and Charles have not yet seen the proposed text -- I'm posting it here first. In order to post my summary of their email (below) on the public list, I'd need their approval and, ideally, confirmation that my summary is correct. Hence I'm posting first to DC-USAGE-BC... Tom ---- Main background, repeated here as reference (see earlier summary of the complete discussion) Proposed definition Definition: "A description of the qualities of the resource in terms of control, display and content that can be used to match the needs and preferences of a user." Comment: "The qualities of control, display and content include the user's control of the interface, the sensory modality of the resource as presented and variations in the expressive form of the information. Recommended best practice is to express the value in a machine-addressable manner such as the W3C Evaluation and Reporting Language (EARL)." UB decision from the meeting notes (2005-10-10) Agreed to change definition to: "A description of the qualities of the resource in terms of control, display and content that can be used to match the needs and preferences of a user." Note: need to clarify comment to indicate what is meant by 'control, display and content' and to note that recommended best practice is to provide a machine-readable statement. Definition on the table as of 11 April Definition: A statement about the ease with which it is possible to use, interact with or comprehend the resource, regardless of the technology used. Comment: Ease of access encompasses the ability to perceive, understand, navigate, or interact with a resource -- digital or physical -- regardless of the technology being used. For example, this element may be used for statements about the accessibility of a resource to people who are permanently or temporarily disabled. Users wishing to associate this element with a description of a resource from the standpoint of accessibility -- a "related description" in terms of the DCMI Abstract Model [CITE] -- should consider expressing the value in a machine-readable language such as the W3C Evaluation and Reporting Language (EARL) [CITE]. Liddy's reaction to the discussion and proposed definition (disclaimer: paraphrased by me). -- The April 11 definition is not acceptable. The definition and comment make a statement that should not be made by DCMI "for many reasons". DCMI would, in effect, be "making all the mistakes of non-experts in the field". -- For Liddy, it is important to hold on to the notion of "can be used to match the needs and preferences of a user." She suggests: "A description of the qualities of the object in terms of accessibility characteristics that can be used to match the needs and preferences of a user." -- Charles agrees, saying that the important thing is that the metadata describes characteristics of the resource that are relevant to its accessibility, "specifically so that appropriate matches can be made between users and resources". -- Liddy agrees about not enumerating "control, display, and content" as "qualities of a resource". She prefers a vaguer wording such as "in terms of accessibility characteristics" because this could be broadened to include physical access and whatever else might be discovered as necessary for wheel-chairs and the like. She would not want to restrict the element at this stage, so that they will be able to describe best practice in a variety of circumstances more easily. -- She does agree with broadening the concept by removing references to specific qualities that restrict the scope of the element. That said, for the purposes of clarification: -- "control" is the human-computer interaction relationship; -- "display or presentation" has to do with the modality -- visual, auditory or tactile; -- "content" has to do with the intellectual contribution of the resource, service, or other object. -- Liddy agrees that access-as-obtain and access-as-use are different things. The problem with the word 'accessibility' is well-known and confusion has occurred in many fora, but it is felt that changing the term used would cause even more confusion. Best practice is to avoid the use of the word 'access' and to always structure sentences so that 'accessibility' can be used. Conversely, the accessibility community carefully avoid referring to obtainability as 'accessibility'. -- Liddy agrees that in the W3C world, accessibility is about "intellectual accessibility" -- things like level of difficulty and language. It also seems to have something to do with the ease with which a resource can be used. According to http://www.w3.org/WAI/ut2/accessibility.html, Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that the Web is designed so that people with disabilities can perceive, understand, navigate, and interact with it effectively, as well as create and contribute content to the Web. Web accessibility addresses all disabilities, including visual, auditory, physical, speech, cognitive, and neurological disabilities. -- Liddy agrees that the proposed Accessibility element is not specifically about "Web Accessibility" in the sense of accessibility to digital resources in the context of the Web. Rather, the "Web" part is the idea that the Web is used to ship around the metadata, and the resources described by that metadata need not be digital. For example, in the educational context they could be physical objects such as text books and work sheets. -- Therefore, she agrees that one could use this element to describe the accessibility of a building. In fact, this has been considered and there is already work underway to establish a vocabulary for event and location physical accessibility (arising from last year's work in MMI-DC in Europe), though in such contexts, she thinks the definition should perhaps refer to 'object' instead of 'resources' because people don't think of buildings as 'resources'. -- She particularly dislikes one of the alternatives we considered ("A statement about the ease with which the resource can be accessed and used, regardless of the technology being used."). The main objections: -- it is quite different from what was proposed; -- it does not convey the purpose of the metadata; -- it uses the bad word (access) in a confusing way, hinting at definitions that have been discredited in the field. -- Commenting on text we considered at one point Factors that determine the ease of access and use of the resource include the control of the interface, the sensory modality of the resource as presented and variations in the expressive form of the information. ...she made the following objections: -- the word 'access' is used incorrectly -- there is an opening for usability in general, which was never intended; -- the term involves a quality judgment, which seems inappropriate for DCMI. -- Liddy did not at all understand our confusion about the the Accessibility property not actually describing the "accessibility" of the resource, but as describing the resource (itself) in the context of a process -- involving a description of the resource and a description of the user -- the outcome of which is an indication of the accessibility of that resource for that user. Liddy says that an accessibility statement describes in strict detail the accessibility qualities of the object just like date has details about a date. In other words, she does not at all understand the notion of Accessibility as denoting a relation between a resource and a _description_ of that resource -- where that description describes those specific attributes of the resource that support such an "accessibility assessment" process. -- Liddy agrees that we should be able to use an Accessibility element for an unstructured plain-literal "accessibility statement". The example she offers is: "This resource conforms to WCAG Level AA". -- Confusingly -- in light of her suggestion above! -- Liddy strongly objects to defining Accessibility as "A statement about the conformance of a resource to a particular accessibility benchmark" (or words to that effect) -- a wording we considered because it seemed to be what some of the Web pages were about. She explains that the accessibility community has done alot of work to get away from this approach. Conformance statements in this field are very problematic and not helpful anyway as there is no known specification to which conformance guarantees accessibility. -- With regard to our confusion about EARL, she reports that David Weinkauf and Anastasia Cheetham have developed a small EARL generator that produces what they are talking about -- see http://tile-gus.atrc.utoronto.ca/acheck/index.html. She points to http://inclusivelearning.ca/TILE/ for a working demo of a production system using this approach. -- Following URLs she provided, I found http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_bestv1p0.html -- a user guide which explains EARL on the example of TILE. This makes the intended process a bit clearer to me. Basically, it involves comparing "profiles" in XML -- on one hand the profile encoding the accessibility needs and preferences of a user, on the other a profile associated with a resource (which is what they want to point with using the Accessibility element): When the TILE authoring tool is used to aggregate and publish learning objects, authors are prompted to provide information about the modality of the resources, stating whether or not they contain auditory, visual, textual, or tactile content, as well as any equivalent alternative resources along with their alternative accessibility properties. This information is captured in the resource meta-data profile. Users, on the other hand, are given the option of creating an ACCLIP profile stating their accessibility needs and preferences. Together, this information is used to determine whether or not a requested primary resource should be substituted or supplemented with an equivalent alternative resource, as well as styled (e.g., CSS) or transformed (e.g., image to ALT text), in order to meet the needs and preferences of the user. -- Charles thinks the technology is reasonably stable in practice but agrees that EARL is not "stable" in terms of process. He therefore agrees that we might drop the reference to EARL, though thinks it is important to recommend something machine-readable. Since DC allows literal text, he figures a plain-text accessibility statement would would be feasible though not very useful.