Accessibility as Adaptability
Systems 2015, 3, 1-x manuscripts; doi:10.3390/systems30x000x
OPEN ACCESS
systems
ISSN 2079-8954
www.mdpi.com/journal/systems
Type of the Paper (Article, Review, Communication, etc.)
Accessibility as Adaptability
Liddy Nevile1,*, Eva Méndez Rodríguez2,†
1 Wallington, Australia; E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
2 Deputy Vice Chancellor of Infrastructures and Environment, Carlos III University of Madrid, Spain; E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.;
† These authors contributed equally to this work.
* Author to whom correspondence should be addressed; E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.;
Tel.: +61-419-312-902.
Academic Editor:
Received: / Accepted: / Published:
Abstract: Adaptations for students are generally thought of as responsive to the intellectual performances and experiences of the students. In this paper, the need for adaptation of the control and content of learning resources to the accessibility needs of students is considered. Accessibility in this sense may need adaptation because the student cannot view images, possibly because they have a vision disability. Adaptation for such circumstances occurs at various levels as will be discussed.
Keywords: adaptation; accessibility; AccessForAll.
1. Introduction
Adaptations for students are generally thought of as responsive to the intellectual performances and experiences of the students. In this paper, the need for adaptation of the control and content of learning resources to the accessibility needs of students is considered. Accessibility in this sense may need adaptation because the student cannot view images, possibly because they are blind. Adaptation for such circumstances occurs at various levels as will be discussed.
2. Background
When the Web was starting to become mainstream, mainly as a result of the development of browsers as led by Mosaic, it became obvious that the very technology that was making the Web so easily available to many users was alienating people who, to that time, had been gaining access to mainstream jobs and activities because of the technology. In particular, just clicking a link, the wonderful contribution of the browsers, left those who could not see the screen and so the link, lost in space. Such a situation could not be tolerated so the World Wide Web Consortium (W3C), at that time newly located at the Massachusetts Institute of Technology, started to work on making sure that all resources in HTML format could be rendered in a variety of ways, including as text which would enable their use without sight in an equivalent fashion.
The W3C Web Accessibility Initiative (W3C/WAI) is still working on this problem of accessibility. It has developed techniques for using the W3C HTML encoding system to enable the necessary adaptations and it has further developed HTML to allow for such possibilities. Currently, HTML is in its fifth version and has many features that can be used to make a single component of a Web resource usable with a range of devices and browser systems.
Concurrently with the ‘accessibility’ work, as it has come to be known, there has been a lot of work developing the facility of resources to adapt to the everyday devices people are using; a variety of browsers, then different devices including hand-held pads, phones, and more. At first sight, there is not a significant difference between what is done in the sense that the resources are adapted according to the capabilities of the device but there is a significant difference from the perspective of the user. What is required by a phone to display a resource effectively is usually determined by the characteristics of the device whereas adaptations for people with disabilities should be determined by them. The former adaptations are known to be associated with what are now called ‘responsive’ resources, while the latter are known as the accessibility adaptations.
In a more recent development, given that it has proved difficult to get publishers to encode their resources so they can be not only responsive but also accessible, a new complementary approach to accessibility has arisen, known as the AccessFor All approach. The authors credit Jutta Treviranus with naming this approach. It, in no way, denies the value of the W3C/WAI work, but recognises that often content authors and providers, or even the specifications, fail to provide resources that can be used by a particular person.
In this paper, we consider three forms of adaptability of resources, especially in an educational context where it is assumed inclusion of all is critical. We are particularly aware of the adoption of MOOCs as a way of offering education to a wide-range of people but that the trap is in that feature: not knowing all the students personally means that more than the usual attention should be given to the kinds of adaptability available. At their peril, content providers ignore the demands of accessibility and deny themselves from 20-50% of the available educational market.
3. Accessibility
The W3C/WAI project has engaged thousands of experts in a crowd-sourced development activity for nearly 20 years. Typically, the work attends to techniques that will satisfy as many access requirements as possible, as simply as possible. No images should be published on a Web page, for example, unless there is a text description of the image. If the image is important in the interpretation of accompanying text, it may need a full-description.
For example, let’s consider this image:
Figure 1. A railway carriage at a road crossing.
The image might just be decorative. On the other hand, the image might be included in the resource to show the size of the text on the sign as compared to the size of the carriage, say. In the first case, a user who does not want images will not want decorative images included in the display and possibly may not even want to know there are such images. In the second case, the user may not want to see the image but could want a description of it that is equally informative as the image itself.
HTML now includes several ways of accommodating the needs of the user in the display of the resource:
a tag that shows the lack of significance of the image (alt=“ ”)
a tag that shows the image is of a train (alt=“train image”), say, and
a tag that describes the image in detail (longdesc=“an image of a red train ….”).
Knowing which tag is as important as what is in the tag. So the possibilities are an ‘ALT’ tag and ‘LONGDESC” tag. These tags are included in the code that embeds the image within the resource so the code for an image might look like this:
<img src="/examples/traincrossings01.jpg" alt=" " >
There are techniques for including images in different contexts that take account of the ways in which users might need them presented. In addition, there are ways of describing images that make them more or less useful to the user. In fact, there are a number of ways of helping users just with respect to an image.
If one has been blind for life, given a description of an image that, in its own way, depends on imagery will not be helpful. For example, ‘a red train like the blue Tasmanian train’ would not be helpful to all users in all circumstances. A blind user might prefer a data table to a map or a graph, for instance. But alternatively, they might want a description of the image as opposed to an interpretation of it, or vice-versa.
When a person with a disability is using an assistive device, such as a screen reader like JAWS, one of the most common such devices, to a certain extent the resource will be adapted to fit the device. Images will not be loaded and displayed, obviously, but the JAWS browser will look for descriptions of any images to substitute for the imagery. But what if there is an image of text, say a grave headstone? The text will not be available to the browser so it should all be available in a text format as well as in the image.
But if a user is not blind, they may simply need to hugely enlarge the content of a resource. This is not as simple as one might think. Most content is published in a light-weight form so there is a limit on the expansion of it with the quality being maintained. This is about the difference between
1000 and
Figure 1. Two renditions of ‘1000’: one clear and the other pixilated.
If a small part of a resource is hugely expanded, maintaining context means there should be a gradual restoration of the context that surrounds what is being seen at the time. Again, if text is in an image, it may be expanded but the imagery will have to be supported by software that renders it neatly, not as it might naturally pixilate when expanded.
Figure 2. A section of text expended but maintained in context.
So far, this paper has considered technical characteristics of accessibility. These issues are typical of those worked on by W3C/WAI. Given that this organisation is concerned with the technical aspects of the Web, it tries to ensure that anything it comes up with should be universally implementable, and testable. It can be stopped by a simple national law, such as when the Web Content Accessibility Guidelines (WCAG) were judged unable to have a requirement for inclusion of a description of the accessibility characteristics of a resource embedded within the resource because it is illegal in the United States to alter, in any way, the official digitised version of Thomas Jefferson’s Declaration of Independence. Other inclusions might be difficult to deal with because, while useful for some, they would not be testable.
After many years of good work on the Web Content Accessibility Guidelines, Helen Petrie and others (Petrie & Bevan, 2009, [1]) tested the uptake of the specifications in the Guidelines. They found that even if publishers followed the Guidelines, not everyone would be able to use the resource. That is, not everything that might be needed has been specified, or there may be a conflict between what is generally useful and what will suit a particular user’s needs. And, sadly, the majority of published resources do not follow the Guidelines. Within contexts, such as the Australian Government, it may be specified that all published content must follow the Guidelines but that is not always possible; it can be very difficult to follow all of them, despite the fact that there are three levels of conformity.
4. Authoring Tools and User Agents
Given the techniques for accessibility in the WCAG often involve encoding something in a particular way, or adding some alternative forms of information, it was realised early in the general accessibility work that if the guidelines could say what should be done for increased accessibility, it should be easy for authors to satisfy these requirements. This meant that authoring tools should be built to help the authors, and so the Authoring Tools Accessibility Guidelines (ATAG) were developed in parallel with the content guidelines. In addition, if the work is done, the browsers should be configurable by the users so they can take advantage of the accessibility work. This led to the yet concurrent development of the User Agent Accessibility Guidelines (UAAG). The guidelines for authoring and browsing tools include requirements for the accessibility of the tools themselves, and for the content they produce or display.
Browsing and authoring tools are marketed competitively and this may be why they do not all follow the relevant guidelines. Browsers such as Internet Explorer boasted features that were, by definition, non-standard and certainly not always WCAG compliant. Microsoft Word, incredibly popular and well-marketed, encouraged users to publish works encoded in their version of HTML but not according to the standards (WCAG specifications) but so as to take advantage of features of Internet Explorer. Adobe offered a very comprehensive authoring tool, Dreamweaver, that could have been adopted in replacement of the Microsoft suite, and produced much ‘better-encoded’ content, but Microsoft’s marketing was far more successful.
It is possible that Microsoft’s market dominance has combined with the excellent promotion of the WCAG so that many governments, and lesser organisations such as educational systems, mandate WCAG but not UAAG or ATAG. Whatever the history, it is clear that very few Web resources are published in universally accessible formats, as envisaged.
5. Accessibility Metadata
In response to the difficulties with the implementation of WCAG, and the, perhaps consequent, lack of support for it, some started to think of other ways of ensuring that users could get access to the content of resources when, for one reason or another, they would not be satisfied by the most common form.
It had been recognised early that asking people to rate their resources as accessible or not (according to WCAG) was not a very good way of identifying the qualities of those resources; especially in contexts where there were punitive implications for indicating that it is other than accessible. Avoiding such judgments, use of metadata to indicate available accessibility characteristics was emerging in the metadata community, specifically in the work of the Dublin Core Metadata Initiative (DCMI).
Recently, the authors observed:
In the case of accessibility, a potential user needs to know such things as if there is a text alternative for an image, if a service can be controlled using only a keyboard or an assistive technology driven by a keyboard, or speech, perhaps. This means that a resource might need to take redundant forms, may not have all components assembled in a fixed format, and might need to be accompanied by an associated but not incorporated description of itself. (Nevile & Méndez, 2015, [2])
After a long gestation period, DCMI adopted the term ‘accessibility’ as a way of providing for accessibility information about a resource. Given the way DCMI metadata works, once there is a stub, such as ‘accessibility,’ it is easy to refine it for local use without the risk of losing information contained in a refined tag. For example, ‘visual accessibility’ might be defined as a refinement of ‘accessibility’ and set of six qualities might be recommended so that a resource could be described by metadata including a term and value such as ‘visual accessibility = text-in-image’ or ‘visual accessibility = “no images” ‘ which could alert users to the fact that the text as published could not be presented by a screen reader or that visibility is not relevant. In the case where someone post hoc developed an audio version of the text in an image, it would be possible using DC Metadata to associate the new resource with the old and show that it has, indeed, an auditory form and so the user is able to avoid visual perception problems. (Copyright issues are not considered in this paper but it is advised that for educational purposes, many jurisdictions permit the creation of alternative forms of resources for registered users with disabilities.)
The DCMI struggled, however, with the idea that some characteristics of resources seemed to relate to the user more than the resource and original DCMI metadata was somehow understood to be all about resources. In fact, metadata is meta-data and it can be used to describe any sort of data, the requirements of a user included.
6. AccessForAll Metadata
The next development of significance, the coining of the term AccessForAll, coincided with the amendment of the UN Declaration of the Rights of People with Disabilities [3] that tried to position people with disabilities as simply people, and avoidance of discrimination by planning their inclusion in all activities, in advance. This approach replaces the earlier one of designing for some mythical ‘normal’ person and then making allowances and modifications for people with disabilities. This is the way AccessForAll work on resources has been interpreted.
AccessForAll implies that it is not for anyone but the user to define their requirements, thus avoiding the labelling of people by their disabilities and the assumptions that have been made in the past about what will be best for them. It is also known that what might suit a particular user may not suit a single other person. This principle had been embedded in the development of Cascading Style Sheets (CSS) and argued for by Charles Nevile for accessibility reasons. He convinced his colleagues developing the CSS specification that it should always be possible for a user to replace a delivered stylesheet with one of their choice, thus adapting a resource to suit their needs where possible.
In the AccessForAll context, the user is enabled to determine the requirements they want to use in a given context for a resource. They are understood to potentially have different requirements according to different circumstances. Thus, a person may not be able to see anything on some occasions but be happy to ask a friend to describe what is to be seen on other occasions. A person without a disability may just not like images, and should be able to specify that they don’t want resources to be delivered with images, but instead with text descriptions of the images. And so on.The principles are clear: the user decides what they need, and in some cases what they might like if it’s available.
So greater accessibility, in the form of inclusion, is expected from a situation in which the user can state their immediate requirements and a resource can be delivered in the form requested. This may mean, of course, that alternative components are required, or that a service might be necessary to create an alternative to some component that does not satisfy the requirements. But it also means that accessibility does not depend on the original author in the old way, or that the resource can be made more accessible by the identification or creation of alternative resources (what the authors like to think of as ‘cumulative accessibility’ or even ‘crowd-sourced accessibility’.
The AccessForAll approach allows for a new definition of accessibility. The emphasis moves from a single published resource, described as accessible or otherwise, to a service that accommodates the individual user’s accessibility profile and uses it to deliver what the individual user wants, adapted or otherwise. An interesting aspect of this is that what might be defined as not accessible according to the WCAG criteria might, nevertheless, be perfect for a given user. In their case, it may not matter whether others can use the resource in that form or not.
AccessForAll makes for a different market-place with respect to accessibility. Instead of having to deliver a universally-accessible resource, a university for example might commit to providing students with an accessible version of the necessary resources within 24 hours. This is a just-in-time approach to accessibility and managed well, could not only be excellent for the users but offer the publishers and learning service providers a huge saving. Their typical failure to have everything accessible just-in-case could be re-engineered to provide a swift, more efficient accessibility service at far less cost.
There have been projects working on these ideas for some time. In 2014 a large publisher of accessible versions of books brought together experts from around the world and together they created a set of terms for the description of resources which were published by Google, Yandex and Yahoo as schema.org metadata. The tags chosen were:
accessibilityFeature, accessibilityHazard, accessibilityAPI, accessibilityControl
(see http://www.w3.org/wiki/WebSchemas/Accessibility)
Very quickly the search engine companies have been able to employ their clever algorithms to describe millions of Web resources according to the chosen tags. This means searches can be performed to quickly discover resources that fit a set of accessibility requirements. By choosing accessibilityFeatures in a software wizard, users should be able to expect the delivery of resources that satisfy their requirements using an accessibility service.
The authors consider that an additional term ‘accessMode’ would be useful. The accessFeatures are what most users or their agents will want to work with, but if they imply the combination of access modes that satisfy the user’s requirements, the management of the search process will be easier. In drafting an international standard for accessibility metadata for education, the relevant sub-committee of the Joint Committee of ISO/IEC has assumed that what is published as the user’s profile of requirements should be expressed in the same terms as the accessibility characteristics of resources, or resource components.
7. Adaptation and Accessibility Metadata
Educational resources and tools are required by law to be accessible in most jurisdictions. Often this is based on notions of discrimination, and so what is provided for students with disabilities may vary in proportion to he perceived need for accessible resources. An Australian example illustrates this well: an online course for podiatry students was at first assumed to need no adaptations because it was assumed no students would have disabilities but a number of the students were, in fact, blind.
For many years, Nevile and others (2009 [4]) have argued that sensible accessibility provision might vary according to the circumstances, with all aspects of the situation and the individual participants undertaking the learning being taken into account, rather than just an objective test of the conformance of the resource to WCAG, however comprehensive WCAG is. This attitude to accessibility extends to the emerging range of online courses. People with disabilities benefit in particular from opportunities to study without having to physically attend classes. In proportion to the general populace, people with disabilities are very disproportionally engaged in education, especially higher education. There is a need for recognition of the market for online education available and accessibility adaptation for learning resources to serve the students who make up this market is crucial.
8. Conclusion
This paper has explained the potential for adaptation of education with an accessibility service to become inclusive. The use of metadata for adaptation as a just-in-time accessibility service is considered as an effective and economically appropriate strategy. The potential for cumulative accessibility of resources, particularly benefitting from the support of the public search engines, is advocated. Adaptability without accessibility is considered inadequate.
Conflicts of Interest
The authors declare no conflict of interest.
References and Notes
Petrie, H., & Bevan, N. (2009). “The evaluation of accessibility, usability and user experience” in The Universal Access Handbook, Stepanidis, C. (ed), CRC Press, 2009. Retrieved September 30th 2015: http://www.nigelbevan.com/papers/The_evaluation_of_accessibility_usability_and_user_experience.pdf
Nevile, L, & Méndez. E, (2015). “Do We Need Application Profiles? Reflections and suggestions from work in DCMI and ISO/IEC” in DC-2015: Proceedings of the International Conference on Dublin Core and Metadata Applications. São Paulo, Brazil, September 1-5, 2015.
United Nations, (2006). Convention on the Rights of Persons with Disabilities. Retrieved September 30th 2015: http://www.un.org/disabilities/default.asp?navid=12&pid=150
Chapman, A; Kelly, B; Nevile, L & Heath, A, (2006). “Personalization and accessibility: integration of library and web approaches” in Proceedings of the 15th international conference on World Wide Web, WWW 2006, Edinburgh, Scotland, UK, May 23-26, 2006; 01/2006
Web References
Dreamweaver http://www.adobe.com/Dreamweaver/
JAWS http://www.freedomscientific.com/Products/Blindness/JAWS/
World Wide Web Consortium (W3C) http://www.w3.org//
W3C Web Content Accessibility initiative (W3C/WAI) http://www.w3.org/WAI/
Web Content Accessibility Guidelines (WCAG) http://www.w3.org/TR/WCAG20/
Authoring Tools Accessibility Guidelines (ATAG) http://www.w3.org/TR/ATAG20/
User Agent Accessibility Guidelines (UAAG) http://www.w3.org/TR/UAAG20/
Dublin Core Metadata Initiative (DCMI) http://dublincore.org/
Cascading Stylesheets (CSS) http://www.w3.org/Style/CSS/
schema.org http://schema.org/