Wikibooks

Open Education Handbook/OER & Accessibility

< Open Education Handbook

(Content taken from chapter of the Into the wild – Technology for open educational resources.)

Accessibility is about the provision of content and services in a manner most suitable to the user, no matter what disability they may have, in order for them to fully participate with it. By sensible design, based on awareness of user needs (and provider responsibilities) the delivery of materials should not present any significant barriers to the user.

Why accessibility is important

edit

Accessibility is absolutely vital for a project to produce truly "open" educational resources. The ethos of "open" is to be accessible – consider "open" in the widest social sense, not (as often illustrated) geographically. If the outputs are not meeting appropriate accessibility requirements then they have failed to be 'open' before they have even left the building, and a sustainability decline has already commenced.

A principal philosophy behind open educational resources is to maximise opportunity for others to be able to engage, not only as recipients but also as potential contributors. For a resource to be adopted (i.e. used "as is") or adapted (i.e. enhanced, disaggregated or integrated into other resources) in another institution it must be attractive in terms of its content and the standards it follows. But accessibility does not have to be onerous or restrictive; a lowest common denominator. It merely needs to be carefully considered to avoid creating accidental barriers and provide alternative routes or enhancements. For a simple example, it may be just provision of an image - perhaps something difficult for another individual to obtain themselves e.g. an electron micrograph captured during a research investigation which would have value for other communities, if it was made readily available to them. Its potential issues have to be considered as soon as possible: its description needs to be concise and accurate (not only to use it but also to discover it) with some authentic provenance; its licence may need to be suitable not only for re-use, but also for editing or annotation for a wider audience including those with disabilities, not as a possibility but as a certainty because it is, by philosophy, open to all. Therefore, some thought needs to be given to its other potential uses before it is exposed to a wider audience: this is necessary for OER projects, it's not "showing off". The resource description therefore can be made to a standard suitable for a radio listener or podcast thereby automatically meeting the needs of visually impaired students. If a quality description is a core element of the resource's metadata then the resource is far more likely to be discovered and reach a wider audience, perhaps drawing more to the project it is embedded within. Another simple example is the use of video transcripts; far easier to translate into other languages and search, and if pre-scripted (thereby providing the accessibility option by default) the narrative is often far more focussed on the topic, a higher quality of output is generated for all.

Programme approaches to accessibility

edit

For a project to meet its accessibility requirements it needs to consider users with disabilities as equal stakeholders to the generic "students" that were probably quoted in the project specification: a project may have assumed that identifying "students" alone was sufficient, using this broad descriptor in its inclusive sense. By recognising "students with disabilities" as separate stakeholders their needs can be addressed with some equivalence, i.e. not as a small fraction of the wider population and therefore an equivalent small fraction of the effort available, a 'bolt-on' solution. The irony is that to solve the requirements for this stakeholder group alone all other non-disabled students are catered for: two tasks collapse into one.

For many projects it has often been thought efficient to create the resources first, then tackle the additional requirements for a series of appropriate "special needs", be it a visual or hearing impairment, or a learning disability like dyslexia. Planning for this retro-fitting is easier, there is no plan! However, it is expensive in terms of time and effort; and difficult to complete in a compressed time-scale towards the end of the project, when the funding is becoming exhausted, as well as the staff. Accessibility is not a process of fine tuning, it's a design principle; there is no reason why this content should not be understood for what it is by anyone who meets it. It is a far easier solution to direct a little effort during the design stage and realise that many other barriers and issues will be removed in this way before they can grow to become difficult hurdles towards the end.

There are many sources of information for solving most digital delivery problems already available in the JISC network, including those from JISC TechDis, where a pedagogical approach to the application of inclusive Accessibility technologies helps explain the issues they address. Note that experiences in one education sector can lend themselves to OER in others. If a resource is to have an impact then it must not hold any unnecessary limitations. The structures and hierarchies of Higher Education will inevitably be challenged by a population circumventing the barriers of its "walled garden".

Reporting requirements for projects need to highlight the value of accessibility for the wider usability and sustainability of the project or initiative. An "Accessibility Challenges, Issues and Benefits" tactic is therefore recommended:

  • Challenges: What would challenge those with visual or hearing impairments, motor difficulties or print impairment? How might alternatives be provided?
  • Issues: How were disabled people included in user testing? What were the situations that arose that required consideration and the decisions made to ensure the resources remained accessible? Did user-testing give valuable feedback?
  • Benefits: How did accessibility improve during the project? What wider benefits might this bring (e.g. accessing on a mobile device, or benefits to ESOL (English for Speakers of Other Languages) students, or enhanced usability)?

The term "disabled student" can be misleading as it can subconsciously imply the disability affects the "studentness" of the individual, whereas thinking of a "student with disabilities" can isolate this issue. The facility to gather, evaluate and synthesise knowledge is rarely affected if suitable (often inexpensive and ubiquitous) technologies are utilised. With appropriate support, disabled students can excel just like any other learner.

Many software solutions to accessibility are available as FOSS - Free and Open Source Software, freely available to download and use at no cost, often without needing a costly technical install if used from a pen-drive or memory-stick. Without adequate environmental provision (including managed software permissions) we are disabling students themselves. OER projects that link to recommended support FOSS support tools would often assist both internal and external users. There are many resources available through JISC TechDis resources to assist with improving accessibility; FOSS resources, techniques and technologies, to tools to help validate the outputs; Sim-dis enables authors to visualise how content may appear to users with disabilities, and the Accessibility Passport helps producers check they have considered other needs.

Issues

edit

During the preliminary Phase One of the UK OER Programme many projects sought to make their outputs accessible but it was often difficult to highlight the advantages of the approach as these were often "taken for granted" and not emphasised. This was highlighted by a survey by Anna Gruszczynska which sought to discover how embedded accessibility as a design process was within UK OER. Gruszczynska notes that although accessibility was a consideration by most respondents, this was less apparent in the outputs, "rarely mentioned or incorporated in the project workflow". For the issue to be addressed it needs to be explicitly reported and disseminated for the benefit of these stakeholders.

Future directions

edit

In the future, the information about the accessibility of a resource may be an expected part of its accompanying metadata; perhaps as part of the Dublin-Core initiatives or community developments in other countries e.g. Merlot.org, to raise the profile of this more professional approach. Publishers are also working with JISC TechDis to create a framework for accessibility as part of EDItEUR. If better metadata becomes coupled with community generated paradata (usage data about learning resources including pedagogic context, inferred through the actions of educators and learners) then more novel uses of resources may be better realised, practice shared, and benefits maximised. Access for all is attainable and sustainable if we know what we want and we can agree how to get it.

Accessibility is a design component best tackled early. Explicit inclusion of accessibility in testing and reporting will considerably improve the usability of the output and links to appropriate FOSS support tools may also help. Finally, consider accessibility as a component of resource metadata to explain to potential users how best to utilise the OER.

Further resources

edit

of repurposing/reuse]

Retrieved from "https://en.wikibooks.org/w/index.php?title=Open_Education_Handbook/OER_%26_Accessibility&oldid=2747329"