Citation: Ng, C., & Schofield, M. (2017). A Practical Starter Guide on Developing Accessible Websites. Code4Lib Journal, (37). (link)
This article from Code4Lib’s July 2017 issue provides users with just what its title suggests: practical advice for including accessibility when developing a website.
The authors focus on ARIA (Accessible Rich Internet Applications), scripting, and semantic markup rather than typical accessibitily how-to article stand-bys like alt text, and provide not only a basic overview of each of their chosen topics but a brief discussion of why each is important in accessible design.
Another thing that makes this article stand out is that it looks at the actual processes web browsers use to render websites. As the authors point out, understanding when and how browsers give information to assistive technologies to make websites accessible to users is important if you’re in the process of developing a website.
One example of this is the authors’ discussion of the accessibility tree, which tells the browser which DOM elements needs to be exported to assitive technologies.
With its focus on the specifics of how browsers make websites accessible and its easily applied best practices, this article is a welcome change from the typical rehash of accessibility how-to guides.
Citation: Elhassan Elsabry. (2017). Claims About Benefits of Open Access to Society (Beyond Academia). In Expanding Perspectives on Open Science: Communities, Cultures and Diversity in Concepts and Practices: Proceedings of the 21st International Conference on Electronic Publishing. Chan, L., & Loizides, F., eds. IOS Press: 34-43. (link)
This study aims to fill a gap in the literature by figuring out the benefits of OA outside of academia.
As the author notes, few studies have been carried out in this area, largely because it’s difficult to gather these data, and–to a certain extent–difficult to even figure out what the benefits might be.
Although the author does intend to try and measure the success of these benefits at some point in the future, this study does not attempt that. Rather, it consists of a review of OA documents (statements and OA declarations; government policies; editorials in journals about OA) to find what they consider “the purpose behind supporting Open Access” (35).
For each of these documents, the author selects keywords about either the benefits of OA or who the beneficiaries of OA are. (The figures in the article are a little unclear about which is being measured, as the first is set out differently than the second and third.)
Interestingly–although perhaps not surprisingly–the author’s study found some differences between the various groups.
While journal editors focus more on benefits to “researchers themselves (e.g. citations, visibility, copyright ownership, etc.)” government policies care more about benefits like “globalization of science, reproducibility, transparency, etc.” (42).
Although the results are interesting, the study doesn’t share any particular insights about them or about OA in general. This is perhaps to be expected from this sort of preliminary study, but it is nonetheless a little disappointing.
Citation: Jhangiani, R.S., & Biswas-Diener, R., eds. (2017). Open: The Philosophy and Practices that are Revolutionizing Education and Science. London: Ubiquity Press.
This collection of essays on open education, open science, and open access, charts the ways the three movements overlap and the impacts they have had—or can have—on education, science, and scholarship.
The collection is split into three sections: Introductory essays describing the history, philosophy, and potential impact of “Open” movements; an “Open Practices” section which contains practical advice and best practices; and a series of case studies.
The editors of the book describe it as “expert commentary on the history, current trends, and future of open education and science (6), and the contents do not disappoint. The range of topics covered in the various chapters, and their focus on practicalities rather than theory, make this a useful text for anyone with an interest in OA or its related “Open” disciplines.
Of particular interest is an essay by F. Dastur, “How to Open an Academic Department” (163-178), which sets forth three guidelines in helping to overcome resistance to change around Open Access and Open Education in your own academic department. Other case studies and “Open Practices” essays will also be relevant and useful to anyone looking to establish a movement toward more open education at their own institution.
Citation: Smith, K.L., & Dickson, K.A. (2017). Open Access and the Future of Scholarly Communication: Implementation. Creating the 21st-Century Academic Library. Lanham, MD: Rowman & Littlefield.
This book of collected essays considers OA from a very specific viewpoint: Academic libraries that want or need to implement OA initiatives at their institution.
Although that’s a relatively narrow focus, a number of very different aspects of OA are considered, among them: copyright and authors’ rights, OA pay-to-publish models, electronic theses and dissertations (ETDs), open data and metadata, and OA publishing of undergraduate research.
A number of the included essays fall into the case study structure fairly typical of academic library research, with insights that–while fine–may be difficult to replicate at other institutions or in other situations. A few are also fairly basic reviews that will be helpful to librarians new to scholarly communication, but not so useful elsewhere.
On the other hand, there are a number of pieces like Zeller and Stenberg’s “Faculty Require Online Distribution of Student Work: Enter the Librarian”, which take a more broadly practical approach to the topic. Zeller and Steinberg’s article, for example, includes a series of appendices librarians can use as checklists when making undergraduate work available under an OA license.
Despite some of its essays being average in execution, the book as a whole is a useful read for the practically-minded librarian with an interest in scholarly communication.
Citation: Pendergast, M.O. (2017) “Evaluating the accessibility of online university education.” International Journal of Online Pedagogy and Course Design, 7(1). (link)
This article presents a relatively recent study of University websites, comparing them to WAI’s WCAG 2.0 at the AA level.
The first 6 pages of the article is taken up with an overview of web accessibility, including: its history; relevant laws and guidelines in Australia, Canada, the United Kingdom and the United States; a quick summary of the WCAG 2.0 guidelines and tools to check accessibility; and brief commentary on implementation in universities.
The author pulled home pages from 24 accredited universities, a mix of public, private, large, and small, and tested them with AChecker to determine how many problems each was likely to have with passing WCAG 2.0 at the AA level. Although several universities had no known or likely problems that were detected by the tool, most had between five and thirty known problems, with a few that had significantly more.
The author then tested a demo course set up at Florida Gulf University (his home institution), starting at the university’s home page and going through the school’s learning management system’s login page. Here, as well, there were known errors on most of the pages, and the author notes finding it “particularly disconcerting” that the login page would have been totally inaccessible to anyone with a visual impairment.
The author’s conclusion is that webmasters, administrators, faculty and staff all need to work harder to make sure course content is accessible. Recommendations include checking each HTML page for compliance before it’s uploaded, checking it routinely, training faculty to use web authoring tools with built-in compliance checkers, making sure that all off-site content from textbook publishers or other vendors is accessible, and being wary of devices and apps (11).
While this conclusion has its heart in the right place, it is a little simplistic, especially given the lack of specific, detailed advice on solving the complex problems that are likely to come up in planning for, implementing, and maintaining accessible web pages.
Overall, the study is too basic to be of broad, practical use. The information it describes may be useful to newcomers, but anyone familiar with web accessibility likely knows all this already. The author also seems to conflate disability with visual disability, although that may just be an artefact of the specific problems found by AChecker, which deal with lack of contrast and other screen-reader-centric errors.
Regardless, given the problems of the article and the simplicity of the study, this article hardly presents the evaluation of “online university education” its title proclaims.
This post is a little different than most of my posts on AOA. Rather than a review of someone else’s work, it’s here to announce the release of a piece of OS software I’ve been working on titled OASiX (Open Access Showcase in XML).
What is OASiX?
OASiX is a lightweight software tool which allows users to create and update a research (or other) showcase by editing and uploading XML files. OASiX runs on JQuery, AJAX, and XML, and its HTML files are responsive.
In the past few decades, libraries have moved beyond their traditional roles of collecting and storing purely physical items such as books, now providing access to electronic materials through databases and other web-based resources. In the academic realm, many libraries also host Open Access (OA) journals or repositories of scholarly data and publications produced by their institution’s faculty members.
Unfortunately, promoting and disseminating OA work produced by faculty generally requires an institution to have a certain level of fiscal or financial support. Commercial showcase products are expensive, and often require an annual subscription, as they are hosted on the vendor’s servers. Open Source (OS) alternatives, while technically free, carry “hidden costs” like work-hours, and require the institution to have on staff someone who can make any required customizations or upgrades.
OASiX (Open Access Showcase in XML) aims to fill the needs of institutions which would like to showcase faculty work, but have neither the budget nor the advanced technical knowledge required by commercial or other OS products. All you need in order to use OASiX is a web site which allows you to upload files, and the ability to edit and create XML files.
OASiX is intended to be a low-tech, high-efficiency alternative to expensive commercial repositories and more complicated OA repositories. Because it does not manage file uploading by default, it is best thought of as a way to showcase faculty work. However, if you have server space to host your own files and do not need to restrict access to them, OASiX can also be used as a repository.
Unless you live in a strange parallel universe where departments are labeled things like “Department of Functional Organization” and people have titles like “Alphabetizer,” you’ll probably want to modify the content of the default showcase.
OASiX is built to make this as easy as updating a few XML files. Each showcase includes the following XML files in a folder helpfully labeled “XML”:
creators.xml – A list of the creators whose works you are showcasing. Includes contact information, a biographical statement, a place to link to a photo, and name, position, and relevant department names. The file contains an example creator, Creator AB, who can be deleted.
works-ABC.xml – This example file lists the works by the showcase’s example creator, Creator AB.
works-TEMPLATE.xml – A template file for adding new creators to the showcase.
admin/settings.xml – Allows you to update settings for your showcase, including contact information, a list of departments, and basic showcase information like the title and about and footer text.
Updating Repository Information
The first step to readying your OASiX showcase for the world is to update the admin/settings.xml file to accurately reflect your institution.
In this file, you’ll enter the name for your showcase and an “about” statement, the institution you’re associated with and their URL, and footer text and an icon. All of these fields are optional, but the more information you can give about your situation the more useful (and findable!) your showcase will be.
Other important information on this page include Administrator contact information for when things go wrong and a list of departments.
The list of departments is essential to OASiX’s operation, so be sure to fill out this section with the departments at your institution.
Adding a Creator
To add a creator to the showcase, you will need to modify both the creators.xml file, add their basic information into the creators.xml file as follows: <creator>
<identifier>A unique identifier for this creator (used to connect the creator with their works-###.xml file</identifier>
<display_name>First Middle Lastname</display_name>
<department>Department Name (must be in the Departments list of admin/settings.xml</department>
<url>a URL associated with the creator</url>
<image>An image of the creator. If left blank, a dummy image will display.</image>
<profile><![CDATA[A biographical statement about the creator. HTML is okay if you leave the CDATA stuff intact.]]></profile>
<date-added>Date added to the showcase</date-added>
<date-modified>Date last modified to the showcase</date-modified>
Each time you add a new creator to the showcase by entering their information in this XML file, you will also need to create a new XML file for them by copying the works-template.xml file and replacing the “template” in the filename with the identifier you’ve chosen for them in the creators.xml file.
Associating Works with a Creator
Each creator has their own XML file for their works.
<identifier>The identifier of the creator + a number (e.g. ABC001)</identifier>
<title>The title of the work. Use CDATA if the title has an ampersand or requires HTML.</title>
<creator>Creator(s) for the work. Can be repeated to list co-authors.</creator>
<type>Type of the work, using DCMI terms (Optional)</type>
<description>A description of the work. It's best to use CDATA if the description is detailed. (Optional) </description>
<title>Title of the journal, website or other source of the work</title>
<date>Date when the work appeared in this source</date>
<format>Format of the source, e.g. print or electronic (Optional)</format>
<paywall>If the source requires a subscription or some other associated cost, mark this with a y. If the work is freely available at the source, mark this with a n. (Optional)</paywall>
<url>A URL to access the work (Optional)</url>
OASiX in Action
Once you’ve added the information to your XML files and uploaded them to your server, you should see your content appear immediately.
OASiX will automatically generate the following pages for you:
A list of creators, complete with job titles and department relationships
A list of departments, complete with associated creator names
A list of published works for each creator, along with a profile page for them
All information you added to the settings will also appear in the relevant places, including on the “contact” page, the home page, and the headers and footers.
The Future of OASiX
Although OASiX is functional, it doesn’t have a lot of the bells and whistles users have come to expect of software in 2017. In the future, I’d like to do more work on an optional administrative interface that allows users to update their repositories through a secured web interface. Other possible upgrades include adding the ability to sort by recency and adding more settings to the Settings.xml file.
I’d also like to enhance the design of the tool, both visually and by increasing its accessibility. (The tool passes WCAG 2.0 at the AA level, but I haven’t tested it thoroughly beyond that.)
Citation: Crespo, R.G., Espada, J.P., & Burgos, D. (2016). Social4all: Definition of specific adaptations in web applications to improve accessibility. Computer Standards & Interfaces 48: 1-9. (link)
Most attempts to make the web accessible for a wider number of users rely on designing accessible websites. This paper describes an approach which works more like screen reading software, by adding a layer of accessibility to websites using a tool created by the authors called Social4all.
The tool works by allowing anybody to input the URL of a website and create an “adaptation profile” which is then stored in a central repository and can be accessed by other users who need to visit the website (p. 3).
The authors tested their system with occupational therapy students, and asked them to assess its ease of use in creating new adaptation profiles. The test users rated the system as easy to understand (p. 7), although it seems as though the system would have to be tested by users with disabilities to be fully assessed as effective.
Overall, the concept is an interesting one to consider, although the language of the article is unclear in some places, which makes for difficult reading at times.
Generally speaking, though, a tool like Social4All should not be seen as a replacement for actual accessible web design. Rather, it might serve as a useful tool for users stuck dealing with otherwise inaccessible websites. Since this is only a preliminary study into the concept, it will be interesting to see what further developments are made.
Tigwell, G.W., Flatla, D.R., & Archibald, N.D. (2017). ACE: A colour palette design tool for balancing aesthetics and accessibility. ACM Transactions on Accessible Computing, 9(2): 1-32.
This article presents a new tool to help web designers manage colour palette design. The authors argue that existing colour palette design tools focus exclusively on aesthetics or accessibility, and are not adequate for the needs of web designers trying to balance creating websites which are accessible for all users with creating ones which are aesthetically pleasing to all users.
The authors describe four “key functions” of an ideal colour palette design tool based on a review of the literature:
1 – The tool needs to allow users to choose an entire palette of colours
2 – The tool needs to allow users to compare many different colour combinations simultaneousy to reduce the time spent meeting WCAG minimum contrast guidelines
3 – The tool should provide an “example website” using the palette chosen
4 – The tool should make problems to users with colour vision deficiency “more explicit” by providing simulations of the sample website (p.2)
The authors then set out to make a tool that could do all of these things, called ACE: the Accessible Colour Evaluator. Much of the rest of the article describes the process of creating and redesigning ACE based on developer feedback. This process is fascinating, and provides a useful look at what goes into creating accessibility tools.
The tool itself is easy to use and , available to use at http://daprlab.com/ace/ should be a valuable asset in any web designer who wants to ensure their sites are more accessible to those with colour vision deficiency.
Citation: Schmutz, S., Sonderegger, A., & Sauer, J. (2016). Implementing Recommendations From Web Accessibility Guidelines. Human Factors: The Journal of Human Factors and Ergonomics Society, 58(4), 611-629. DOI 10.1177/0018720816640962
This article explores whether implementing web accessibility guideline recommendations can make a website less usable or less pleasant for non-disabled users (spoiler: it doesn’t).
Noting a lack of research into the effects of disability guidelines on non-disabled users (no longer true, incidentally, since I’ve reviewed at least one other recent article on the topic and have read several others), the authors carried out a study on sixty-one “nondisabled” university students, requiring them to access three web sites, one of which conformed to WCAG 2.0 at the AA level, one at the A level, and one at the NA level (pp. 614-615).
The study measured the amount of time it took the students to complete a number of tasks, and additionally asked them to rate each of the three web sites in the areas of usability, aesthetics, trustworthiness, and perceived workload. Findings were, perhaps unsurprisingly, that “the AA Web site showed advantages over the two other Web sites with regard to performance and subjective evaluations” (p. 620). Sites that just passed the A level of WCAG seemed to confer no benefit, however.
The authors conclude that what causes the AA level web sites to be more usable and effective for users with no obvious disability is “a combined effect” of the various criteria at that level such as structure, text alignment, clear labeling of forms, etcetera.
My only complaint is that, presumably because the article focuses on the experiences of “nondisabled” users, the authors sometimes appear to conflate the purpose of WCAG and other accessibility guidelines with making sites accessible to those with vision problems and nothing else. There are also a few times where it sounds like the authors are saying that WCAG’s recommendations on tabbing order are irrelevant to all users, even though they are talking only of those with no disabilities.
Despite this minor flaw, this article is yet another nail in the coffin of the old “accessible websites are ugly and unusable for the rest of us” myth. As the authors put it, their study helps show that WCAG can be “a helpful tool for designing more usable web sites” regardless of the ability level of the end user (p. 623).
Citation: Aizpurua, A., Harper, S., & Vigo, M. (2016). Exploring the relationship between web accessibility and user experience. International Journal of Human-Computer Studies, 19: 13-23 (Note: page numbers below are from the preprint version of the article)
This article argues that web accessibility and user experience are closely related, although it does not find a significant correlation between adherence to WCAG 2.0 and many of the desirable elements of user experience of a website.
The bulk of the article describes the results of a study of eleven blind web users’ experience with local restaurant websites. Pages from these sites were organized into highly accessible and poorly accessible, based on the Barrier Walkthrough method and the AA conformance level of WCAG 2.0 (p. 8). The test participants were then given three tasks to complete on each website, and rated these tasks with words from the “emotion word prompt list”: annoyed, bored, confident, confused, disappointed, frustrated, happy, interested, hopeful, pleased and unsure (p. 10). Participants also rated the websites themselves with the “Attracdiff” tool, which “consists of a set of 23 word pairs reflecting opposite adjectives that can be rated on a 7-point scale,” e.g. “complicated/simple” (p. 11).
Findings of the study included that accessible sites were more likely to be rated with positive emotions and positive adjectives by non-sighted users, and that inaccessible sites were more likely to be rated with negative ones. They further suggest that it may be possible to reverse engineer the process and determine some level of the sight’s accessibility by gauging its perceived usability–although they do not go into detail about this, and it certainly shouldn’t be considered a viable alternative to accessibility testing.