= DCMI Accessibility Wiki = (For information about Wikis and how to use this Wiki, please see the bottom of the page. For quick links to the many pages in this wiki, see below.) == Quick introduction == Dublin Core metadata is designed to be easy-to-use and ubiquitous. A single DC term should convey important information that can be complemented by other metadata where suitable. For people with disabilities who use assistive technologies, very detailed metadata about their needs and the characteristics of a resource may be necessary if they are to have good access to information. The single term 'accessibility' has been designed to perform the duties of a DC term: the information it conveys should help users with limitations on their access facilities identify potential problems with a resource. It seems that no more than about 3% of resources are, in fact, compliant with the guidelines for accessibility [1]. Even if they are so compliant, they might, or might not be suitable for a particular user. A resource may be inaccessible to a user as it is first published but subsequently it, or a part of it, may be replaced or augmented by an accessible alternative, such as a text description of an image. In this case, the intended use of the DC accessibility term includes: * discovery of a resource for an individual user that is suitable for their use; * discovery that the original resource has content that will not be accessible to the individual user; * discovery of an alternative resource that does not have the same potential problem; * discovery of a resource component (e.g. text description of an image) that will be accessible. It should be noted that the term is for description of components of resources, individual resources, and collections of resources. The term is expected to be easy to use and yet powerful in that it deals with a large number of the problems that trouble at least 20% of users and can be inconvenient for 65% of users [2]. The accessibility term is designed to support the 'AccessForAll' [3] strategy for matching resources to the needs and preferences of individual users, especially, but not exclusively, for those with permanent disabilities. The original AccessForAll work was done at the ATRC [4] at the University of Toronto. It was implemented in the Inclusive Learning Exchange [5]. It was further developed by IMS GLC [6] and the DC Accessibility Community, resulting in IMS standards for description of resources [7] and personal needs and preferences [8]. The ATRC and IMS versions were made by and for education. The DC version is not different in any way but, as with all DC metadata, can be used for a wide range of resources. (Technically speaking, this means the 'domain' of the term is the same as that for the 15 DC terms.) ISO/IEC JTC1 adopted the AccessForAll work and has published the first three parts of the AccessForAll standard [9]. These include an introductory Part 1 (ISO/IEC N24751-1:2009); Part 2 that describes how to write descriptions of user needs and preferences for digital resources (ISO/IEC N24751-2:2009) and Part 3 that describes how to write resource descriptions (ISO/IEC N24751-3:2009) for matching them to the needs and preferences. Other parts are being currently being developed. The DC accessibility term is designed to be useful as a single term. The earlier versions of AccessForAll were based on LOM-style metadata [10] and involved the use of a number of terms that were based on a different metadata model. It is likely that they will be revised to operate on a model that is the same as, if not very similar to that of DC metadata. The earlier versions may become, in DC language, application profiles for accessibility, and a DC-conformant accessibility application profile is also likely in the future. It is expected that the single DC accessibility term will be very useful to most people troubled by disabilities but that the detailed application profiles will be necessary for people with severe disabilities or producers of resources for such people (e.g. alternative format providers). === References === 1. DRC Report. "The web: Access and inclusion for disabled people. DRC Formal Investigation report" at http://www.equalityhumanrights.com/en/publicationsandresources/Documents/Disability/web_access_and_inclusion.pdf 2. Microsoft. "Identifying Who Is Likely to Benefit from the Use of Accessible Technology" Retrieved 2007-01-14 from http://www.microsoft.com/enable/research/whobenefits.aspx Archived 2008-10-15 by WebCite® at http://www.webcitation.org/5bZm1ZRwB 3. Nevile, L. (2005). "Adaptability And Accessibility: A New Framework" in Proceedings of OZCHI 2005, Canberra, Australia. November 23 - 25, 2005. ACM (the Association for Computing Machinery) Digital Library. Retrieved 2008-12-09 from http://delivery.acm.org/10.1145/1110000/1108413/p21-nevile.pdf?key1=1108413&key2=2075188221&coll=ACM&dl=ACM&CFID=14456173&CFTOKEN=26161489 4. ATRC (Adaptive Technology Resource Center) at http://atrc.utoronto.ca/ 5. TILE (The Inclusive Learning Exchange) at http://www.barrierfree.ca/tile/ 6. IMS GLC (IMS Global Learning Consortium) at http://www.imsglobal.org/ 7. See IMS Accessibility at http://www.imsglobal.org/accessibility/ 8. See IMS Accessibility at http://www.imsglobal.org/accessibility/ 9. ISO/IEC standards N24751-1:2009, N24751-2:2009, N24751-3:2009 10. IEEE LOM (Learning Object Metadata) IEEE 14.84.12.1 - 2002 Standard for Learning Object Metadata: http://www.ieeeltsc.org/standards/1484-12-1-2002 == Use Cases == The following use cases have been adapted from those used for the corresponding ISO/IEC JTC1 N24751-3:2009 standard. Scenario 1: Discovery and Retrieval of Alternate Training Content Sophia is a participant in a distance training program. She is blind and uses a computer equipped with a screen reader that converts on-screen text into both Braille and synthetic speech. At the start of the program, Sophia uses a "preference wizard" which asks her questions regarding her preferred content settings. She records that she would prefer aural alternatives to visual content, when available, but can use her computer's voice output to read text aloud if necessary. When finished editing her preferences, the preference wizard produces a Personal Needs and Preferences (PNP) file that is saved in the content management system's user database. The resources for students have been described using the DC accessibility term indicating any limitations that might be problematic for students. For today's assignment, Sophia is required to complete 3 of 5 provided exercises. When she logs in and requests the exercises, the system compares her PNP file and the metadata for the exercises to determine if the exercises are suitable for her needs. The metadata associated with each exercise indicates that all 5 contain visual content. The system then determines that there are text descriptions available for 2 out of 5 of the resources: one has a text description of the visual content embedded in the resource file, and the other has a separate text description. One resource has only visual content. One exercise is wholly in text and is adaptable according to the W3C WAI guidelines for accessibility [??]. The fourth exercise consists of an audio file on a Webpage that is activated by clicking on an image. The last exercise has an image of a bronze plate engraved with historic information. It is accompanied by an audio file that not only describes what is in the photo, but also the historical context etc. The system informs Sophie that, based on her needs, the content of 4 of the 5 exercises will be accessible to her despite the fact that only one of them would be classified as 'accessible' according to the W3C WAI guidelines. She selects the three she wishes to complete, giving a sigh of relief that she is able to skip the least interesting one. As she calls up her chosen exercises, the system automatically transforms each resource by displaying the text description rather than the image, drawing the text either from within the original file or from the associated separate text descriptions, as necessary. Scenario 2: Extreme Instructional Environments Airline maintenance staff receive regular training sessions, but there is always the possibility of the need for "ad hoc" instruction. Available airplane resource materials include video instructions on aircraft engine maintenance that detail the methods for repairing various engine problems. Usually such material is wanted in a noisy hangar in which workers are required to wear hearing protection. There may also be multiple information systems connected to their ear-phones for safety reasons. In this environment, workers use portable computers to view the reference materials as they carry out the repair exercises. When workers log into the information system, they indicate the hangar as their context to indicate they will not be able to hear any audio content. They will require text transcripts or animated diagrams to replace audio content. When selecting the training videos, the system automatically searches for and retrieves the available text captions or alternative visual content and supplements the video with them while synchronizing it to the original audio. As a result, the workers are able to reference videos as they work in the hangar. Scenario 3: Creating a Repository for Federated Searching A lecturer for a course in social history produces an online module that is based around recordings of songs from the American Civil Rights movement. The diction on the recordings is not very clear. Tony has a minor cognitive disability and a partial hearing loss and the hearing loss prevents him from hearing the words of some of the songs. He does not wish anyone to know about his disabilities, particularly not the course lecturer. The student is normally provided with services to help him with his studies by the disabled student services office. When he informs his assistant from that office that he cannot hear the words of some of the songs, she writes text captions for the songs he cannot hear. She writes accessibility metadata for each set of captions she writes, indicating that they contain only transformable text that is W3C WAI conformant. She deposits the caption files and their metadata in the office’s repository. The learning environment the university uses is configured to search the disability office’s repository for alternatives for content. When Tony searches online for the songs, the learning environment picks up the requirement for captions and searches the disability office's repository to discover the captions. Tony's university is a member of a consortium of universities that share learn resources and disability alternative formats. The accessibility metadata for the resources is shared along with all other metadata. == New Dublin Core Term == The new term, labeled 'accessibility', will be used for a property that is defined as "A characteristic of a resource that relates to the human capacity to perceive, operate, understand or otherwise engage with the resource." Any resource may have a number of such properties, so, in the usual way, this term may be repeated in any description of a resource. A ''universally'' accessible resource will either be so as it is, i.e. alone, or will indicate and connect to the components necessary for its use by an individual. Because the term is designed to be able to interoperate with, and support, a full AccessForAll description of a resource, there is a recommended vocabulary to go with the term. This is a set of terms (application profile) that will indicate exactly how a resource is suitable for an individual user or alert them to potential problems with a resource and the possible need for an additional or alternative component if they are to use the resource. Such extra material can be identified by the DC term 'relation' or refinements of that term. If a resource does not have all necessary components when it is first published, they can later be connected to it by metadata. An example of the use of the accessibility term is a case where there is an image published by a friend after a picnic. If the image is labeled as 'visualOnly' then someone else might add a text description of the image for the benefit of a person who is visually impaired. If the original was a video, then someone interested in the video may not be able to hear and so text captions of the dialogue might be added, etc. In some cases, an alternative will already exist and just need to be connected to the original resource. AccessForAll supports the process of automated matching of resource components to an individual's access needs and preferences profile. Using the accessibility term, resources that are suitable for a particular user with special needs can be identified. Currently, it is not possible to sort resources in advance or to discover only suitable resources. In addition, resources can be made more accessible, over time, by third parties, for a wider range of users. The United Nation's Convention on the Rights of People with Disabilities [1] has been signed by many countries and thus there is a huge need everywhere for resources that are suitable for such people. It is hoped that every resource description will soon include the accessibility term as it will make a great difference to many users' ability to participate in the information space. 1. UN Enable, (2008). Map of Signatures and Ratifications. Retrieved 2008-04-03 and archived 2008-11-04 by WebCite® at http://www.webcitation.org/5c64wfoUj For the full term proposal, see NewElementProposal For the draft application profile, see the ApplicationProfileAbstractModel and ElementsVocabularies == Potential use of DC AccessForAll metadata == * many DC creation tools are based on schema that can be augmented/replaced - the new schema can be 'slotted in'; * DC-based metadata applications, in general, will understand the accessibility term because it is DC Abstract Model compliant; * standard DC users and those with application profiles for communities such as governments, education and even public broadcasting will add the accessibility term to their metadata; * website developers will use the accessibility term to customise their sites to the needs of individual users, not just classes of users; * website builders who have communities with special needs will use the accessibility term and the refinements of it in application profiles to address their community's needs, * etc. == Quick Links == * AccessForAllFramework: explanation of the AccessForAll approach to resource accessibility * NewElementProposal: requirements table for the proposed DC.accessibility term * Draft SkosTerminology of accessibility term * Draft SkosTerminology of a vocabulary for the accessibility term * ApplicationProfileAbstractModel (terms and values in UML diagram) * BetaVersion of AfA accessibility profile * ElementsVocabularies * Draft of accessibility vocabulary as SkosTerminology * ImplementersNews - page for news and views * EducationAndOutreach resources for AccessForAll metadata * Draft UserGuidelines * AccessForAllCitations meetings and other participatory events for wide consultation about the AccessForAll work * [http://dublincore.org/groups/access/ DC Accessibility Community homepage] * [http://dublincore.org/tools/ Information about tools for creating and working with Dublin Core metadata] * DC 2008 Conference Accessibility Session See DraftSessionAgenda2008 === Outstanding Tasks === Technical 1. finalise full AccessForAll terminology 2. register AccessForAll schema with vocabularies for terms 3. develop AccessForAll descriptions for user's needs and preferences 4. provide cross-walks? Practical 1. provide guidelines for AccessForAll implementation 2. publish some 'very good' examples of implementation === Cancore work - guidelines for using Access For All (in IEEE LOM) === * Cancore AccessForAll Metadata Guidelines for IEEE LOM: now available at http://www.cancore.ca/guidelines/drd (These are also available in French: http://www.cancore.ca/lignes_directrices/drn). * [http://www.cancore.ca/editors.html A list of authoring tools for making AccessForAll IEEE LOM metadata] === See also === * WCAG 2.0 amendments for metadata - LN * attachment:WCAG-metadata-proposal-LN.html == Issues for Discussion on this Wiki == This Wiki is here to solicit constructive comment on the issues. Please feel free to send your comments to the DC Accessibility community email list. If you are interested in tracking discussion on any issues, you need to register and then subscribe to the page. This means you will get notification of changes made to that page. Your name and address will not be given to anyone or used for any other purposes. == Archived pages == Discussion pages no longer active: * EuAccessibilityQualityMark * ExamplesOfAccessibilityTermUsage * AdaptabilityOrAccessibility * AccessibilityIssuesDiscussion * ResponseToUsageBoard: WG response to UB decision of 2005-06-13 * CharterProposal: 2006 charter proposal for the DC-Accessibility working group * DC Conference Sessions - SessionReport DC2005. Also see notes online at (thanks to Charles McCathieNevile and David Weinkauf). * ISO CD1 EditingDiscussionItems * DiscussionOfFcd * CancoreAccessForAllMetadataGuidelines: CanCore Wiki discussion page * W3C WAI proposal for RolesAndAdaptability discussion page * discussion page for public comment on ISO FCD AccessForAllDrafts * draft of a possible DC AccessForAllApplicationProfile (to be used only as a working document) * a form that gives 'a sense of' the kind of questions that will be required for metadata creation - try http://www.ozewai.org/A4A/Draft-AP-6-3.html * DC 2007 Conference Accessibility Session See DraftSessionAgenda2007 == DC Accessibility Wiki == A WikiWikiWeb is a collaborative hypertext environment, with an emphasis on easy access to and modification of information. This wiki can also link to InterWiki space. You can edit any page by pressing the link at the bottom of the page. Capitalized words joined together form a WikiName, which hyperlinks to another page. The highlighted title searches for all pages that link to the current page. Pages which do not yet exist are linked with a question mark: just follow the link and you can add a definition. Rather than 'edit' text, please just add comments starting with your name so we know from whom they came, e.g. Liddy Nevile: Accessibility should be redefined as ..... To get an overview of this site and what it contains, see the SiteNavigation page. To learn more about what a WikiWikiWeb is, read about WhyWikiWorks and the WikiNature. Also, consult the WikiWikiWebFaq. === Interesting starting points: === * RecentChanges: see where people are currently working * HelpForBeginners: to get you going * WikiSandPit: feel free to change this page and experiment with editing * FindPage: search or browse the database in various ways * SyntaxReference ---- CategoryHomepage CategoryHomepage
tags technorati :