Accessibility and Metadata in Digital Libraries
David McArthur and Sarah Giersch
Eduprise
Accessibility and Metadata 8 SMETE/NSDL White Paper
Overview
This brief white paper complements a larger analysis of SMETE (and, more generally, NSDL) metadata elements and the prospects for mapping their diverse controlled vocabularies. Focused relatively narrowly, it analyzes the roles that various metadata elements could play in providing accessibility information about the library resources to which they refer. The first section provides a brief background on accessibility issues and approaches. The next examines the elements that NSDL (and SMETE) has provisionally adopted as its discovery metadata core. After that, additional elements that could be relevant to access—primarily from the IMS/IEEE specifications—are reviewed. The paper concludes with a short speculative discussion of the services through which such resource metadata could be used to further access.
Background
Accessibility, and the related issues of equity and the digital divide, loom large in digital libraries. However, the term is subject to several interpretations. Some view it relatively narrowly in terms of disabilities (principally motor, perceptual and cognitive) and the design of web content for people with those limitations (see for example, the Web Accessibility Initiative of the W3C (W3C, 1999)). At the other end of the spectrum, accessibility may be interpreted as anything that helps any users overcome barriers to obtaining digital resources. This white paper adopts a middle ground: accessibility in a digital library context, on this interpretation, means improving the ability of relatively well-defined classes of disadvantaged users to find and make effective use of the library’s resources.
There are a several approaches to improving accessibility in the context of digital libraries, and the Web in general, in part reflecting the different interpretations of this vague concept. A number of organizations, such as W3C (W3C, 1999) and Access.edu (ACCESS, 2001) provide detailed information and guidelines for designing accessible web sites. Several offer online tools, like Bobby (CAST, 2001), built on these principles, that analyze a Web site for accessibility. Some sites, such as the Michigan Teacher Network (MTN, 2001), are actively acquiring accessible online collections. And yet other groups are developing ideas and technologies to improve the discovery of accessible content in existing digital libraries.
The thesis of this paper is that metadata can be used to support accessibility in connection with improved discovery. The simple idea is that certain metadata elements provide information about what capabilities are needed—either perceptual-motor, cognitive, socio-economic or geographical[1]—to make use of a resource. This, in turn can improve the ability of classes of users who are disadvantaged in these ways to find resources that meet their needs—and avoid ones that do not. The paper reviews a range of metadata elements from this perspective on accessibility.
Review of NSDL metadata elements
The review of metadata elements for those relevant to accessibility, defined broadly as above, begins with the ones the NSDL Standards workgroup has put forth as the recommended metadata elements[2]. Table 1 lists each element, its originating source, a definition[3], as well as the overall the overall accessibility needs to which the element is relevant. Although such needs certainly do not reflect a comprehensive theory of accessibility and access deficits, they do reflect the common barriers (perceptual-motor, cognitive, socio-economic and geographical), noted above, that characterize many classes of disadvantaged users. Thus, Format is marked as relevant to a perceptual-motor access need because sight-impaired users, for example, might want to know whether a resource was an image or (preferably) text or audio.
Element /Source
/ Definition / Access Need /Title / DC / A name given to the resource
Creator / DC / An entity primarily responsible for making the content of the resource
Subject / DC / The topic of the content of the resource
Description / DC / An account of the content of the resource
Publisher / DC / An entity responsible for making the resource available
Contributor / DC / An entity responsible for making contributions to the content of the resource
Date / DC / A date associated with an event in the life cycle of the resource
Type / DC / The nature or genre of the content of the resource / Cognitive
Format / DC / The physical or digital manifestation of the resource / Perceptual-motor
Identifier / DC / A Reference to a resource from which the present resource is derived
Source / DC / A Reference to a resource from which the present resource is derived
Language / DC / A language of the intellectual content of the resource / Cognitive, Socio-Economic
Relation / DC / A reference to a related resource
Coverage / DC / The extent or scope of the content of the resource / Geographical,
Socio-economic
Rights / DC / Information about rights held in and over the resource / Socio-Economic
Audience / DC-ED / A category of user for whom the resource is intended / Cognitive, Socio-Economic
Standards / DC-ED / A reference to an established education or training standard to which the resource is associated / Cognitive, Socio-economic
InteractivityType / IEEE / The flow of interaction between this resource and the intended user / Cognitive
InteractivityLevel / IEEE / The degree of interactivity between the end user and this resource
TypicalLearningTime / IEEE / Approximate or typical time it takes to work with this resource
Table 1—NSDL Metadata Elements and Accessibility Needs
Note that not all elements in Table 1 are marked as relevant to accessibility, even though in theory, all information could help inform access. For example, Creator is not included, but it might be the most effective way to access, say, the works of a specific author who is of special interest to a particular disadvantaged minority. However, criterion for inclusion, as noted above, is whether or not the element provides information that might be systemically relevant to accessibility for a disadvantaged community. This is also why Subject is excluded. That said, examples such as this demonstrate that it is often not clear-cut whether or not a metadata element is relevant to an access need.
For those elements marked as relevant to accessibility in Table 1, following is a general discussion motivating the decision, in some cases including a notional example:
Type: This element, as Dublin Core (DC) acknowledges, may need redefinition, or at least better controlled vocabularies (see DC’s current Type vocabulary at http://dublincore.org/documents/dcmi-type-vocabulary/) . However it can provide some information about the use of a resource (e.g., interactive resource), which would be important to classes of learners that prefer certain learning styles. In addition, it describes modality (e.g., text, sound, image), which would be useful, for instance, to hearing or sight-impaired users.
Format: Like Type, this element provides information about the perceptual requirements of a resource. For example, a jpeg resource might not be of interest to a sight-impaired library user. The technical type of the resource also helps to understand the hardware, software and other equipment needed to use the resource. Such information could useful to economically disadvantaged users who do not have access to high-priced tools required to play a resource.
Language: This element is certainly important to all users; however, it may be especially useful in guiding ethnic minorities to resources in their native languages.
Coverage: Assuming that that access has a geographical component (for example, most of the people on the wrong side of the digital divide are in developing nations), then geographically disadvantaged communities might benefit from access to resources covering their locales. The coverage metadata element could be used to mark resources in this way.
Rights: In almost all metadata schemes and implementations this is now simply a placeholder, but eventually it may be part of a rights management system[4]. At a minimum, this could provide information about price, helping steer some economically disadvantaged users to free resources, if necessary. More ambitiously, in for-profit libraries it may be a hook, say, for subsidy schemes that provide reduced-cost access to selected classes of users.
Audience: This is a vague but important metadata element, still in the draft proposal stage from Dublin Core’s Education (DC-ED) Working Group (Dublin Core 2000). Audience is supposed to capture end-user or ultimate beneficiary; Mediator (a qualifier) is an agent that mediates access, such as a teacher. Currently there no recommended vocabulary scheme for this element from DC-ED. But there is no reason why Audience could not be used to earmark specific disadvantaged communities. In fact, GEM’s vocabulary for this element (ultimate beneficiary) clearly reflects exactly this access-related use (GEM, 1999), as does ALGS’s EEO (Equal Opportunity) scheme (ALGS, 2000). For example, GEM’s controlled vocabulary includes terms such as at-risk students, hearing-impaired students, rural students and vision-impaired students. As such, it represents one of the few attempts to explicitly encode accessibility information into metadata.
Standards: This is another draft-proposal element from the DC-ED Working Group that is intended to provide information to communities that have specific skill-related training and educational needs. Although this is not exclusively an issue for disadvantaged communities, the educationally underserved might profit substantially from this information.
InteractivityType: The current best practice vocabularies for this element (from DC and IMS/IEEE) are very impoverished. However, it might describe the way in which students use a resource, which, in turn could be important to classes of users that have a preferred learning style (see also Type, above, and Learning and Teaching Processes/Characteristics, below).
Review of additional metadata elements
The following elements are not from the NSDL core set, but rather from other specifications, in particular IEEE/IMS[5]. If their relevance to accessibility appears significant, they might be considered as new candidate metadata elements for SMETE and NSDL.
Element /Source
/ Definition / Access Need /Technical.Size / IEEE/
IMS / The size of the digital learning object in bytes / Socio-economic
Technical.Requirements / IEEE/
IMS / Digital platform resources needed to access and use the resource / Socio-economic
Technical.OtherPlatform
Requirements / IEEE/
IMS / Information about other software and hardware requirements / Socio-economic
Educational.
LearningResourceType / IEEE/
IMS / Specific kind of learning object, most dominant kind first / Cognitive
Educational.Learning
Context / IEEE/
IMS / The principal environment within which the learning and use of this learning object is intended to take place / Cognitive
Learning and Teaching Processes / Characteristics / DC-ED[6] / The activities and methods associated with various types of teaching and learning. / Cognitive
Table 2—Additional Metadata Elements and Accessibility Needs
Following is a discussion of the additional elements listed in Table 2:
Technical.Size: This and other technical metadata elements (below) might be relevant to accessibility because collectively they communicate the machine, software and network demands of a resource, all of which are related to cost of access. Some disadvantaged communities may, for example, not have high-speed Internet access and may choose not to download large resources.
Technical.Requirements: The subelements of this (including type, name, installation remarks and other platform requirements) essentially provide a rich description of the technical demands of a resource, and are relevant to accessibility in the manner noted in connection with Technical.Size, above.
Educational.LearningResourceType: It is not clear whether this element is fundamentally different from DC.Type; however, the recommended vocabulary terms for LearningResourceType (see IEEE LOM, 2001) in some cases come closer to capturing resource characteristics that might be important to classes of users who have a preferred learning style. Michigan Teacher Network’s (MTN 2001b) resource type vocabulary is also richer than the default terms for DC.Type, and is therefore more useful in describing resources in an accessible way. That said, these vocabulary are actually more characterizations of the resource than user, and so address the access needs of users only indirectly. The provisional Learning and Teaching Processes/Characteristics, below, may be more appropriate for this accessibility need.
Educational.LearningContext: This element, as well as the provisional DC-ED Level (see http://www.ischool.washington.edu/sasutton/dc-ed/Dc-ac/DC-Education_Report.html#level), are intended to capture information such as grade level, course level, and perhaps age group. Although grade level is often a poor surrogate for the cognitive demands or level of a resource, there are whole classes of users at-risk because of cognitive mismatches between resources and their needs, and this is one rudimentary way to address that access problem. Related IMS/IEEE elements such as Difficulty and TypicalAgeRange (and also Audience, using some schemes) roughly address the same need, but perhaps even more crudely.
Learning and Teaching Processes/Characteristics: This is an open area of discussion in DC Education Working Group, not a provisional metadata element. But consensus here appears to be converging on metadata elements that will describe a mix of pedagogical processes and learning styles associated with digital resources and their uses. These terms, when are articulated, will almost certainly be relevant to describing cognitive accessibility needs.
General Discussion
This analysis indicates that a number of metadata elements can facilitate access by providing information that can help relatively well-defined classes of disadvantaged users make effective use of digital library materials. But the relevance of metadata to accessibility is currently limited in several respects. For one, several of the elements reviewed above are not uniformly relevant, nor are excluded elements always unrelated to access. Perhaps more importantly, some of the potentially most useful elements, such as Learning and Teaching Processes/Characteristics, are still in flux, hence inappropriate to include in the SMETE or NSDL core metadata set at this time. Further, even elements that are stable, such as LearningResourceType and Audience, lack mature vocabularies. All this limits the roles that metadata elements can currently play in describing learning resources in terms of accessibility to disadvantaged communities.
As noted above, metadata is a relatively unexplored approach to enhancing accessibility. However, a number of steps can be taken to overcome some of its limitations, and to increase its importance as a way of improving the accessibility of digital library resources. Very briefly:
Craft metadata elements and vocabularies that explicitly encode accessibility information. None of the metadata elements reviewed above are purpose-built to describe library resources in terms of accessibility, which in part accounts for why some of the examples seem contrived. However, elements and vocabularies can be specifically designed with access in mind. For example, GEM’s formative vocabulary for Audience, noted above, already explicitly references some classes of disadvantaged students and teachers. These terms can be substantially extended to capture other access limitations or needs. By the same token, elements that address styles of teaching and learning are, potentially, equally relevant to accessibility and should be refined to reflect various cognitive needs and preferences. DC-ED (Dublin Core 2000) is making substantial progress in this area, as are UKOLN (UKOLN, 2000) and ALGS (ALGS, 2000), on the international front.