Making Journals Accessible Front & Back: Examining Open Journal Systems at CSU Northridge Manuscript Citation: The following APA style citations may be used to reference this manuscript: Borchard, L., Biondo, M., Kutay, S., Morck, D., & Weiss, A. (2015). Making journals accessible front & back: Examining open journal systems at CSU Northridge. Retrieved from http://scholarworks.csun.edu Version of Record Information: Citation: Borchard, L., Biondo, M., Kutay, S., Morck, D., & Weiss, A. (2015). Making journals accessible front & back: Examining open journal systems at CSU Northridge. OCLC Systems & Services: International Digital Library Perspectives, 31(1), 35-50. Copyright: Copyright © Emerald Publishing Limited DOI: http://dx.doi.org/10.1108/OCLC-02-2014-0013 This item was retrieved from CSUN ScholarWorks, the open-access, institutional repository of California State University, Northridge. http://scholarworks.csun.edu This is the author’s penultimate, peer-reviewed, post-print manuscript as accepted for publication. The publisher-formatted PDF may be available through the journal web site or, your college and university library. http://dx.doi.org/10.1108/OCLC-02-2014-0013 http://scholarworks.csun.edu/ Structured Abstract: Title: Making Journals Accessible Front & Back: Examining Open Journal Systems at CSU Northridge Author(s): Laurie Borchard, Michael Biondo, Stephen Kutay, David Morck, Andrew Weiss Journal: OCLC Systems and Services: International Digital Library Perspectives Year: 2014 Purpose – This study examines Public Knowledge Project (PKP) Open Journal Systems for its overall web accessibility and compliance with the Federal Electronic and Information Technology Accessibility and Compliance Act, also known as Section 508. Design/methodology/approach – 21 individual web pages in the CSUN test instance of PKP’s OJS version 2.4.0 used in three back-end journal development user roles were examined using three web-accessibility tools (WAVE, Fangs, Functional Accessibility Evaluator). Errors in accessibility were then logged and mapped to specific Web Content Accessibility Guidelines (WCAG) criteria. Findings – In all, 202 accessibility errors were reported across the 21 Open Journal System pages selected for testing. Because of this, the OJS cannot be efficiently utilized by assistive technologies and therefore does not pass the minimal level of acceptability as described in the Web Content Accessibility Guidelines 2.0. However, the authors found that the types of errors reported in this study could be simply and effectively remedied. Research limitations/implications – Further studies will need to corroborate on a larger scale the problems of accessibility found in the specific pages. Only three user roles were examined; other roles will need to be analyzed for their own problems with accessibility. Finally, although specific errors were noted, most can be easily fixed. Practical implications – There is an important need for accessible software design. In the case of CSUN, one of our campus partners will be better served by improving the web accessibility of our online open access journals. Originality/value – Although many studies and analyses of Section 508 compliance of front-facing web resources have been conducted, very few appear to address the back-end of such tools. This is the first to examine what problems in accessibility journal users with disabilities might encounter as OJS system administrators, journal managers or journal editors. Keywords: accessibility, accessible software design, library publishing, Open Journal Systems, open access, open source software design, Federal Electronic and Information Technology Accessibility and Compliance Act, Section 508, web accessibility Article Type: Research paper I. Project Overview The emerging role of the library as publisher is an example of how librarians have become not only organizers of information but also facilitators of knowledge creation. With this new role, however, comes the responsibility to provide publishing tools that are accessible to all users through compliance with the American Disabilities Act (ADA). Although analyses of front-end user interfaces have been prevalent, examinations of the administration and editing functionality of these publishing platforms has been overlooked. In response to this need, this article reports on the findings of a pilot project, implemented at the Oviatt Library at California State University, Northridge, which examines the open source publishing platform Open Journal System (OJS). Usability testing was conducted on the administration and editing functions to determine non-ADA compliant issues for this subset of specialized back-end users. California State University Northridge (CSUN) is located in the center of the San Fernando Valley, 25 miles north of Los Angeles. CSUN is comprised of a diverse population of over 38,000 students (approximately 86-90% undergraduate) and 4,000 faculty members across 9 different colleges, including the university library. The Oviatt Library is located in the center of campus and serves CSUN students, faculty and staff, along with the local community. There are over 30 tenured or tenure track librarians with two major departments covering reference and technical services. In fall 2012 the library conducted strategic planning with special so-called “diagonal slice” groups dedicated to public service, print and e-resource management, space utilization, and marketing. Out of this strategic planning came the development of the Digital Publishing Implementation Group (DPI group). This working group’s original charge was to position Oviatt’s institutional repository, ScholarWorks, as a central CSUN open access mandated press and publisher of e-texts, journals, as well as a repository for open educational resources. Along with this internal mandate within the library, in August 2013 CSUN’s president, Dianne Harrison, signed the Berlin Declaration of Open Access, making open access initiatives a priority for all of the campus. Later, in November 2013, CSUN’s Faculty Senate also passed an Open Access Resolution encouraging the faculty to publish and archive their work in open access repositories. Given the current push on campus for open access initiatives, the DPI group felt it was imperative to provide a recommendation for publishing open journals in order to contribute to and help foster the nascent campus open access movement. As the DPI group initially convened, it was decided that it would be best to develop a pilot project where members would experiment with publishing a journal using a more user-friendly open journal platform rather than relying entirely on CSUN’s ScholarWorks DSpace institutional repository. Although a central part of the campus’ open access movement through its ETDs mandate, ScholarWorks was seen as insufficient overall for journal publishing as DSpace does not provide sufficient workflows and user roles for the various tasks found in journal publishing. As a result, alternative open journal software platforms were researched and discussed, but eventually Public Knowledge Project’s (PKP) Open Journal Systems (OJS) was chosen for the DPIG journal publishing pilot project. Following this, the DPI group discussed current CSUN publications and campus entities that might be willing to partner with the group. The group initially reached out to CSUN’s Center on Disabilities, which supports and implements the Annual International Technology and Persons with Disabilities Conference. Although the conference has been held for nearly 30 years, the COD has only just begun to publish conference proceedings via the Journal on Technology and Persons with Disabilities. The group met with Sean Goggin, the Technologies Manager at the Center on Disabilities, in early September. At that time he expressed his willingness to participate, but he also shared his experience with using OJS in the past. Mr. Goggin described some of the issues his staff had encountered with the inaccessibility of OJS for contributors and editors with disabilities. Despite the issues raised, the Journal on Technology and Persons with Disabilities was included in the initial pilot project along with three other journals, The Northridge Review, a creative writing journal for CSUN students; the California Geographer, the journal for the California Geographic society (formerly edited by CSUN faculty); and the New Journal of Student Research Abstracts, a journal publishing the abstracts of science projects created by students in K-12 and edited by CSUN Biology Department emeritus faculty member, Steven Oppenheimer. These journals were chosen because each represents various constituencies and potential user-groups and target audiences found at and outside of CSUN. The Journal on Technology and Persons with Disabilities, for example, despite being centered at CSUN, has a unique, international, decidedly non-CSUN audience with very specific user-needs. In particular, COD has the distinct need for accessible software. The Northridge Review is a CSUN student in-house publication designed to highlight the creative writing of the English Departments students, but it is currently published only in print version. The California Geographer was chosen because it had previously been scanned in entirety and placed in ScholarWorks (Biondo and Weiss 2013). As a result it is a prime candidate to compare the functionality of either OJS or DSpace. Finally the New Journal of Student Research Abstracts was chosen for its outreach role in fostering K-12 education. Each of the four journals during this pilot, then, would be able to provide different perspectives on the utility of OJS. A note on the installation of OJS In order to create a testing and development environment for OJS, an Intel Xeon based server was repurposed locally for the DPI group’s test environment. The server was reformatted and Red Hat Enterprise Linux Server 6.4 was installed and configured to send and receive from a static IP (internet protocol address) reserved for the library. Once the operating system was installed and configured to send and receive on the Oviatt Library’s IP, Apache 2.2.15 was installed, built and configured on August 2, 2013, with firewall protection in place to limit access to local campus IP ranges. Once Apache was properly serving web data additional services were installed via Red Hat’s package system which included: PHP 5.3.3 (Personal Home Page dynamic web programming language), MySQL 5.1.69 (open source database and management), and phpMyAdmin (web based database management). The DPI group chose to go with OJS version 2.4.2, which was the latest stable release at the time of installation. The downloaded package was then extracted into our server’s document root, and permissions were granted to the specified directories to be writeable. A directory for OJS uploads was created below the document root to maintain a secure upload directory. A database user was created via phpMyAdmin to enable the installation script to work properly. Relevant server, administrative user and configuration information was entered into the config.inc.php file provided with the OJS installation. Once everything was configured correctly the command-line installation option was used, which populated the OJS database using the previously created database user. After this the site was serving correctly to browsers, and access to the administrative interface was tested successfully. The only other modifications made were some slight changes to the CSS (cascading style sheets) for aesthetic purposes. II. Background: Accessibility, Open Access publishing & accessible software design This case study was formulated to determine the feasibility of using OJS to provide a viable publishing platform for the aforementioned Journal on Technology & Persons with Disabilities. The DPI group wanted to assess which features of the software could possibly present problems to those with disabilities who would assume organizational and editorial roles within the publication. Accessibility In 1998, the Federal Electronic and Information Technology Accessibility and Compliance Act was added as an amendment to the Rehabilitation Act of 1973. Commonly known as Section 508, the amendment dictates that all Federal agencies must make information equally usable, and accessible to disabled individuals through the use of assistive technology and proper construction of governmental webpages. Mandates of Section 508 have also been codified at state and local government levels for organizations that deal with Federal agencies or receive Federal funds. Likewise, these accessibility standards are broadly supported by the World Wide Web Consortium (W3C). The W3C formed the Web Content Accessibility Guidelines Working Group and in 1999 adopted the industry standard: Web Content Accessibility Guidelines 1.0 (WCAG). An updated version known as WCAG 2.0 was recommended in 2008. These standards are in place across the California State University system, where it is “viewed as a necessity and an investment.” (CSU web accessibility FAQ 2014) Such standards form the basis for the case study. Literature review A number of articles have been written concerning Section 508 of the Rehabilitation Act and the accessibility of academic library websites. The most recent of these is the exhaustive follow-up done by Comeaux and Schmetzke in 2012, which seeks to highlight a “snapshot of web accessibility” across the webpages of 56 North American academic libraries (Comeaux and Schmetzke 2012). They found that accessibility is on the rise as a result of a trio of factors. First, more academic libraries have shifted their online presence to content management systems such as Drupal. Second, the use of CSS for web page layout has allowed for more accessible design. Finally, the adoption of campus-wide policies and standards for institutional webpages has greatly contributed to the development of web pages accessible to all. Similarly, in their article “Differently Able” published in 2011, Cassner et al. found that the “large majority of ARL libraries (88%) [had] a web page for people with disabilities” (Cassner, Maxey-Harris and Anaya 2011). While these two recent works examine the front-end usability of academic library websites and making information accessible, we found that little has been written about the need to make information- creation and publishing tools such as OJS more accessible and usable for people with disabilities on the back end. Indeed, a search for literature related to the use of OJS and its compliance with Section 508 of the Americans with Disabilities Act has turned up little relevant literature. Some of this can be attributed to the relative novelty of library publishing. The Library Publishing Toolkit, published in the summer of 2013, provides the most current and comprehensive collection of experiences of library publishing, as well as discussion of trends in scholarly publishing. Accessibility, however, is only mentioned in broad terms, as merely something to consider, and it is never discussed in detail and certainly not in terms of the back-end editing functionality of a software platform. Cowan (2013) includes accessibility issues in her workflow checklist under technical Considerations. Newton, et al., (2013) state that accessibility and usability principles are adhered to for their projects, but do not discuss these principles in greater detail. MacGregor, et al. (2013) discuss the Public Knowledge Project and focus their chapter on reviewing the embedded workflow within OJS. However, the accessibility issues with the back end of the OJS tool itself are not discussed and were not reviewed. PKP’s discussion forums for OJS were also searched for topics relating to accessibility issues and ADA compliance. Only one discussion topic was found in relation ADA compliance. The topic thread started in 2008 with a user enquiring whether OJS would work with screen readers such as JAWS. A representative from the PKP support team at that time stated that they had not tested the product with screen readers, but they were working on becoming completely 508 compliant and they encouraged more user feedback. In 2010 another OJS user commented that they had run a journal table of contents through WAVE and identified problems relating to labels for language and the two search fields. Once again a representative from PKP promptly replied and stated they were working on becoming completely 508 compliant, but they had in fact not spent much time “determining where we might be slack” (MacGregor 2010). The OJS representative provided a list of recommendations based on a project they were currently working on and once again encouraged more user feedback. Apart from the example cited above, the authors have been unable to find a more recent discussion in the OJS forums that PKP support offers. This particular discussion indicates that although the developers claim to be working on being completely 508 compliant, they do not yet appear to have completed extensive usability/accessibility tests (OJS). As a result of this dearth of scholarship indicating the OJS’s overall level of web accessibility, the authors decided to implement web usability tests. The DPI group first checked the front-end accessibility of the OJS pages by implementing several software solutions designed to test compliance with web accessibility. Prior to this study, the authors first checked the front-end accessibility of the OJS pages by implementing several software solutions designed to test compliance for web accessibility. The first, called WAVE toolbar (which is a plug-in for the Mozilla Firefox browser), checks the content displayed on a webpage and provides visual notifications of non-compliance at the exact locations within a webpage. To corroborate these red flags in accessibility, FANGS, a screen reader simulator for Mozilla Firefox browsers was installed to estimate what a disabled user might encounter using assistive technologies. Finally, the Firefox Accessibility Evaluation Toolbar (FAE) developed by the University of Illinois Urbana-Champaign, was deployed to identify accessibility markup issues within the HTML code. (See Table 1) TABLE 1: Accessibility Tools and Resources Utilized Name of Tool or Resource Summary of Tool or Resource Online Resources Related to Tool or Resource Functional Accessibility Evaluator (FAE) Web and browser based accessibility testing tool from the Illinois Center for Information Technology and Web Accessibility (iCITA) which includes a range of tools for validating and testing webpages. Browser version was utilized for our testing. • Browser Toolbar: https://addons.mozilla.org/en- US/firefox/addon/accessibility- evaluation-toolb/ • Online Tool: http://fae.cita.uiuc.edu/ FANGS Screen reader emulation tool. Renders a text version of webpages to represent how a screen reader would interpret the semantic markup. • Browser Toolbar: https://addons.mozilla.org/en- US/firefox/addon/fangs-screen- reader-emulator/ WAVE Web Accessibility Evaluation Tool (WAVE) from WebAIM (Web Accessibility in Mind, based at Utah State University), creates WAVE accessibility reports in browser, or is able to send to wave.webaim.org for detailed reports. Also analyzes structure, and order. Is able to provide text overlays on live pages with accessibility concerns labelled. • Browser Toolbar: http://wave.webaim.org/toolbar/ • Online Accessibility Evaluation Tool: http://wave.webaim.org/ • WebAIM Home: http://webaim.org/ Section 508 Section 508 Amendment to the Rehabilitation Act of 1973 is a federal act that requires Federal agencies to electronic and information technology is accessible to people with disabilities, and provides guidelines to facilitate accessibility. • Section 508 Homepage: https://www.section508.gov/ WCAG Web Content Accessibility Guidelines, developed through W3C (World Wide Web Consortium) in order to provide guidelines for web content developers, tool developers, and policy makers to create accessible • WCAG Guidelines Home: http://www.w3.org/WAI/intro/wcag https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/ http://wave.webaim.org/toolbar/ http://wave.webaim.org/toolbar/ http://webaim.org/ http://webaim.org/ content for those with disabilities. W3C The World Wide Web Consortium is an organization which works with developers, vendors, and organizations in an effort to standardize core principles and components of the World Wide Web. • W3C Home: http://www.w3.org/ Table 1. The resources and technologies used for determining ADA compliance include W3C, WCAG, FANGS, WAVE, FAE. Each are described above. After running the tests, it was determined that OJS provides sufficient ADA compliance for outward-facing content display pages. Those with disabilities are likely to find no issues with accessing the content as long as those developing the content on the back end ensure that they provide ADA-compliant content. The functionality exists to allow journal creators, editors, and managers to publish ADA compliant content. However, given the increasing need for accessible software design, the authors decided to focus on the accessibility of back-end development pages, which would allow those with disabilities to participate in content creation, journal maintenance and administration, editing, and peer-reviewing. One of the main issues raised by our inquiry is the need for web-based digital tools -- especially those in the open source domain -- that are themselves ADA compliant. Based upon our examination of the literature and the perceived lack of in-depth analysis of ADA compliance in open source software design, our essential question is to examine whether PKP’s OJS would work across three major back-end user roles for people with disabilities. III. Methodology For this study the authors examined the implementation of accessible functionality across 21 back-end web pages specific to three user roles in the CSUN- installed instance of the OJS (version 2.4.2.0) for their adherence to ADA section 508 criteria. (See Figure 1 below.) Figure 1. Screenshot showing the 9 pages analyzed for the OJS California Geographer Journal Editor role, including the following: Editor Home, Unassigned, In Review, In Editing, Archives, Create Issue, Notify Users, Future Issues, Back Issues. The procedure was as follows: first, selected pages were examined via the WAVE program and their warnings and findings were noted. (WebAim 2014) Second, the Mozilla browser plug-in FANGS accessibility simulator was applied to each page to approximate what a person using such software would hear using a screen reader application. (Mozilla Foundation) The FANGS output confirmed the significance of the errors reported by the WAVE evaluator. Third, a report from the Functional Accessibility Evaluator (FAE) was generated for each page to examine issues of accessibility not addressed directly by either WAVE or FANGS. (FAE 2014) The errors found on each page were recorded, tallied, and mapped to a Section 508 compliance checklist developed by the W3C from the Web Content Accessibility Guidelines version 2.0. (W3C 2013) These guidelines provide success criteria from which ADA compliance is measured. As OJS allows for multiple user roles to be created, it was determined that those roles most used during the journal building process would be examined for their adherence to these ADA section 508 criteria. As a result, Site Administrator workflow pages, Journal Manager workflow pages and Journal Editor workflow pages were examined. A total of 21 unique web pages were examined, including 7 Site Administrator pages, 5 Journal Manager pages, and 9 Journal Editor pages. Within these roles the specific user pages examined are as follows: A. Site Administrator user role [7 pages]: Site Management: · [Page 1] Site Settings · [Page 2] Hosted Journals · [Page 3] Languages · [Page 4] Authentication Sources · [Page 5] Categories nistrative Functions: · [Page 6] System Information · [Page 7] Merge Users B. Journal Manager (California Geographer) user role [5 pages]: Journal Setup: Five Steps to a Journal Web Site · [Page 1] Details: Name of journal, ISSN, contacts, sponsors, and search engines. · [Page 2] Policies: Focus, peer review, sections, privacy, security, and additional about items. · [Page 3] Submissions: Author guidelines, copyright, and indexing (including registration). · [Page 4] Management: Access and security, scheduling, announcements, copyediting, layout, and proofreading. · [Page 5] The Look: Homepage header, content, journal header, footer, navigation bar, and style sheet. Journal Editor (California Geographer) user role [9 pages]: [Page 1] Editor Home Submissions · [Page 2] Unassigned · [Page 3] In Review · [Page 4] In Editing · [Page 5] Archives Issues · [Page 6] Create Issue · [Page 7] Notify Users · [Page 8] Future Issues · [Page 9] Back Issues Each web page within the OJS system’s designated user role was examined as outlined above and the results archived as individual PDFs indicating their adherence to specific ADA Section 508 criteria. The results of the accessibility tests for each role and page are explained in the following section. IV. Results Combined reports from both the WAVE and FAE evaluators reveal a total of 202 accessibility errors across the twenty-one pages selected from the OJS Web application (See Table 2). These errors were mapped to the following five associated WCAG 2.0 criteria, listed below in order of frequency: 1. Criterion 1.3.1 - Info and Relationships (166 errors). This success criterion ensures “that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes” (W3C, 2013). 2. Criterion 3.1.1 – Language of Page (21 errors). This success criterion ensures “that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly” (W3C, 2013). 3. Criterion 2.4.6 - Headings and Labels (7 errors). This success criterion helps “users understand what information is contained in Web pages and how that information is organized” (W3C, 2013). 4. Criterion 2.4.4 - Link Purpose (4 errors). This success criterion helps “users understand the purpose of each link so they can decide whether they want to follow the link” (W3C, 2013). 5. Criterion 4.1.1 – Parsing (4 errors). This success criterion ensures “that user agents, including assistive technologies, can accurately interpret and parse content” (W3C, 2013). TABLE 2: Total Accessibility Errors OJS Page 1.3.1 Relation- ships 2.4.4 Link Text 2.4.6 Naviga- tion 3.1.1 Lang- uage 4.1.1 Structure Total Admin 1 - Site Setting 5 n/a 1 1 1 8 Admin 2 - Journals 2 2 n/a 1 n/a 5 Admin 3 - Languages 3 n/a n/a 1 n/a 4 Admin 4 - Authentication 3 n/a n/a 1 1 5 Admin 5 - Categories 2 n/a n/a 1 n/a 3 Admin 6 - System Info 2 n/a n/a 1 n/a 3 Admin 7 - Merge Users 7 n/a n/a 1 n/a 8 Manager 1 - Details 1 n/a n/a 1 n/a 2 Manager 2 - Policies 9 n/a n/a 1 n/a 10 Manager 3 - Guiding Subs 35 n/a n/a 1 n/a 36 Manager 4 - Mng. Journal 9 n/a n/a 1 n/a 10 Manager 5 - Custom Look 24 n/a 3 1 n/a 28 Editor 1 - Home 10 n/a n/a 1 n/a 11 Editor 2 - Subs - Unassigned 12 n/a n/a 1 n/a 13 Editor 3 - Subs - In Review 12 n/a n/a 1 1 14 Editor 4 - Subs - In Editing 12 n/a n/a 1 1 14 Editor 5 - Subs - Archives 12 n/a n/a 1 n/a 13 Editor 6 - Issues - Create 2 n/a 2 1 n/a 5 Editor 7 - Issues - Notify 3 n/a 1 1 n/a 5 Editor 8 - Issues - Future n/a n/a n/a 1 n/a 1 Editor 9 - Issues - Back 1 2 n/a 1 n/a 4 Totals 166 4 7 21 4 202 Table 2. Combined accessibility errors as reported from WAVE and FAE evaluators and mapped to WCAG 2.0 criteria. Independent analysis of errors reported by the WAVE evaluator identified accessibility issues occurring in the front-end interface in 19 of the 21 pages (See Table 3). Of these, ‘missing form labels’ (WCAG 2.0, 1.3.1) was the most commonly cited error at 149 instances. This is followed by: 6 instances of ‘orphaned form labels’ (WCAG 2.0, 2.4.6); 4 instances of ‘problematic link text’ (WCAG 2.0, 2.4.4); and 1 “multiple form labels’ (WCAG 2.0, 2.4.6). TABLE 3: WAVE Accessibility Errors OJS Page WAVE Error Description WCAG 2.0 Criterion Error Instances Admin 1 - Site Setting Missing form label 1.3.1 4 Orphaned form label 2.4.6 1 Admin 2 - Journals Missing form label 1.3.1 2 Problematic link text 2.4.4 2 Admin 3 - Languages Missing form label 1.3.1 3 Admin 4 - Authentication Missing form label 1.3.1 3 Admin 5 - Categories Missing form label 1.3.1 2 Admin 6 - System Info Missing form label 1.3.1 2 Admin 7 - Merge Users Missing form label 1.3.1 7 Manager 1 - Details No errors n/a 0 Manager 2 - Policies Missing form label 1.3.1 8 Manager 3 - Guiding Subs. Missing form label 1.3.1 23 Manager 4 - Mng. Journal Missing form label 1.3.1 8 Manager 5 - Custom Look Missing form label 1.3.1 24 Orphaned form label 2.4.6 3 Editor 1 - Home Missing form label 1.3.1 10 Editor 2 - Subs - Unassigned Missing form label 1.3.1 12 Editor 3 - Subs - In Review Missing form label 1.3.1 12 Editor 4 - Subs - In Editing Missing form label 1.3.1 12 Editor 5 - Subs - Archives Missing form label 1.3.1 12 Editor 6 - Issues - Create Missing form label 1.3.1 1 Orphaned form label 2.4.6 1 Multiple form labels 2.4.6 1 Editor 7 - Issues - Notify Missing form label 1.3.1 3 Orphaned form label 2.4.6 1 Editor 8 - Issues - Future No errors n/a 0 Editor 9 - Issues - Back Missing form label 1.3.1 1 Problematic link text 2.4.4 2 Total 160 Table 3. Accessibility errors reported using the WAVE Accessibility evaluator. Independent analysis of errors reported by the FAE evaluator identified accessibility issues occurring in the underlying code across all pages (See Table 4). Of these, ‘no language attribute’ (WCAG 2.0, 3.1.1) was the most commonly cited error, occurring in all pages with 21 total instances. This is followed by: 11 instances of ‘two or more levels of nesting’ (WCAG 2.0, 1.3.1); 4 instances of ‘improperly nested headings’ (WCAG 2.0, 4.1.1); and 2 instances each of ‘no table summary’, ‘no table header ID’, and ‘no table header’ (WCAG 2.0, 1.3.1). TABLE 4: FAE Accessibility Errors OJS Page FAE Error Description WCAG 2.0 Criterion Error Instances Admin 1 - Site Setting No language attribute 3.1.1 1 Heading improperly nested 4.1.1 1 2+ levels of nesting 1.3.1 1 Admin 2 - Journals No language attribute 3.1.1 1 Admin 3 - Languages No language attribute 3.1.1 1 Admin 4 - Authentication No language attribute 3.1.1 1 Heading improperly nested 4.1.1 1 Admin 5 - Categories No language attribute 3.1.1 1 Admin 6 - System Info No language attribute 3.1.1 1 Admin 7 - Merge Users No language attribute 3.1.1 1 Manager 1 - Details No language attribute 3.1.1 1 2+ levels of nesting 1.3.1 1 Manager 2 - Policies No Language attribute 3.1.1 1 2+ levels of nesting 1.3.1 1 Manager 3 - Guiding Subs. No language attribute 3.1.1 1 No Table summary 1.3.1 2 No table header ID 1.3.1 2 No table header 1.3.1 2 2+ levels of nesting 1.3.1 6 Manager 4 - Mng. Journal No language attribute 3.1.1 1 2+ levels of nesting 1.3.1 1 Manager 5 - Custom Look No language attribute 3.1.1 1 Editor 1 - Home No language attribute 3.1.1 1 Editor 2 - Subs - Unassigned No language attribute 3.1.1 1 Editor 3 - Subs - In Review No language attribute 3.1.1 1 Heading improperly nested 4.1.1 1 Editor 4 - Subs - In Editing No language attribute 3.1.1 1 Heading improperly nested 4.1.1 1 Editor 5 - Subs - Archives No language attribute 3.1.1 1 Editor 6 - Issues - Create No language attribute 3.1.1 1 2+ levels of nesting 1.3.1 1 Editor 7 - Issues - Notify No language attribute 3.1.1 1 Editor 8 - Issues - Future No language attribute 3.1.1 1 Editor 9 - Issues - Back No language attribute 3.1.1 1 Total 42 Table 4. Accessibility errors reported using the Firefox Accessibility evaluator. Analysis of the pages assigned to ‘user types’ in our study reveals the highest number of accessibility errors were within the ‘manager’ pages with 86 accessibility errors. The pages assigned for use by ‘editors’ contained 80 accessibility errors. The pages designated for site ‘administrators’ had the fewest accessibility errors at 36. Among all three user types, errors within the WCAG 2.0 1.3.1 success criterion were most prevalent due to the high occurrence of form boxes that did not contain labels. V. Discussion: Implications and quick fixes Immediate implications of the results: Given the lack of in-depth analysis in library and information science literature, analyzing the design of the back end helps us to determine as librarians whether or not a proposed software will help users with disabilities. What the authors have found in this study is that although the software functions tolerably well on the display side, the back-end pages exhibited several distinct non-accessible behaviors. Essentially there were five distinct WCAG criteria determined to have specific errors detectable by the three tools employed. The first most commonly discovered error -- found on all pages examined and designated as criterion 1.3.1 by WCAG -- is defined as “Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.” (W3C, 2013) The results in tests showed that generally the lack of form labels in the pages contribute to the possibility of overlooked or misunderstood input prompts. The lack of form labels on the pages examined actually hides the fact that forms for input exist. A person with disabilities using a screen reader would not recognize the form box for which to supply information regarding the journal. (See figure 2) Figure 2: Screenshot showing results of the WAVE analysis of “Editor Home” webpage. Various issues of accessibility, including missing form tags are indicated with red flags. This page showed 10 accessibility errors according to the software. Additionally, under criterion 1.3.1., nine of the pages sampled with the FAE test indicated two levels of nesting were found in the headings and tables. Additionally, tables were found to be missing header attributes and header IDs. These are relatively minor but still result in less information being conveyed to the disabled user. Assistive technologies must be able to interpret relationships between elements found on the page to ensure accurate rendering from within the assistive technology. The second most common error, found on all pages and designated as criterion 3.1.1 by WCAG, is defined as “The primary natural language or languages of the Web unit can be programmatically determined.” (W3C, 2013) The results show that although the lack of a defined language appears on all pages, this is mainly a minor inconvenience. It is likely to have a no impact on users, unless language translations are required. The third most common error, found on 5 of the pages and designated as criterion 2.4.6 by WCAG, is defined as “When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content.” Criterion 2.4.6 does not require labels, as in 1.3.1, but rather requires existing labeled elements be logically interpreted. The results show that a few of the form labels indicated in the pages are orphaned from their respective form boxes. As a result, these labels are not properly ordered within the page. Additionally, if the form labels are not accurately describing the correct form boxes, these boxes are thus ambiguous in their definitions on the page, further causing problems with sequential navigation. The fourth most common error, found on 4 of the pages and designated as criterion 4.1.1 by WCAG, is defined as “Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous.” These are primarily found to be problematic by the FAE tool in the form of improperly nested headings. Again, the problem is that those relying on readers may not necessarily understand the parts without the screen reader spelling them out. The fifth most common error, found on 2 of the pages and designated as criterion 2.4.4 by WCAG, is defined as “Each link is programmatically associated with text from which its purpose can be determined.” These are manifest in the OJS pages as problematic link texts. Essentially the links are not working in these cases. Though likely a minor issue, the breakage of such links is still an issue with links that do not provide alternative text for which an agent using a screen reader can understand the action or destination intended by the link. Addressing Issues of Accessibility The majority of the accessibility issues that were presented were missing form labels, and missing language definitions – the majority of the missing form labels are from the inward facing administration pages, and not as often with forward facing publicly accessible pages. OJS has templates left open and editable on the server side, which could be modified to address these issues by adding form labels and the use of meta tags in the sections of the pages to give a language definition. While we installed 2.4.2 as a stable release for OJS, we have yet to patch to the newest (2.4.3) version. The risk that is run here is that any changes to the templating system may be patched over when upgrading versions; however, this has not been established yet as a problem. As result of this, any changes that are made would have to be documented, in case they need to be re-established. One option is to fork a version of OJS from their github repository and share back any commits to the project in the hopes that the changes would be implemented in a future public release. Another feature missing from OJS is the lack of keyboard shortcuts to enable the up, down, left and right arrows in screen readers, which would have to be addressed programmatically. As noted above, some tables lack summaries, captions, row and column headers. The tables designated purely for layout should be summarized to notate this, and tables with tabular data should have clearly defined row and column headers in order to be accessible. However, this could be easily addressed with some templating changes. In several of the administrative sections there is a problem of lack of link text relating to navigation, and abbreviations that are not semantically marked up to provide explanations. Again, these issues could be addressed in templating and can ultimately be adopted back into the project by PKP. VI. Future Studies, Limitations and Conclusion Impact on CSUN’s future in journal publishing As the OJS is a prime candidate for the development of a CSUN-based library Open Access publishing platform, its adherence to current university-wide web policy becomes more important. As CSUN has been mandated to adhere as closely as possible to ADA standards, using OJS for official university publishing must therefore meet the established guidelines for web presence. As a result, it may be somewhat problematic to establish OJS as the go-to publishing tool without significant discussion and analysis of its ADA compliance. As the authors intend the CSUN Open Journals to be used by all of its stakeholders, including faculty, staff and students, compliance for all aspects of the software becomes essential. Limitations of the study: Although the study was able to pinpoint some errors in accessibility, there are some limitations to the study that should be addressed. Awareness of such limitations nonetheless will help to indicate how future studies might create more accurate results. First, the study was conducted without examining other similar types of software or similar online publishing platforms housing digital content such as DSpace, CONTENTdm, and the like. Additionally, though the most current at the time, a new version of OJS has been developed. As a result further studies would be advised to examine similar types of products for their adherence to ADA Section 508 guidelines as well as looking at the future updates of the software. Next, only selected roles (the three most common as assumed by the authors) and selected pages were chosen for the test. This represents a less-than complete examination of the web functionality of the whole site. A more comprehensive examination would need to examine a significantly higher number of pages. Such a small sample is not representative of everything. Finally, there is no one universal tool to definitively examine all aspects of section 508 compliance. For this study multiple tools were needed to analyze the site, yet each tool provides different overall analyses. It is possible that a fourth or even a fifth tool would indicate further errors not found by the others. Conclusions: It will be imperative for those interested in ADA compliance to examine whether more appropriate alternatives to the OJS exist. Although the front end of most software is largely ADA compliant, there is indeed a need for more tools to be ADA compliant themselves for the users of such tools. This emphasis on accessible software design will likely be an important aspect for all web-based software tools. Ultimately the authors find that the back end of the PKP OJS software platform will pose some problems for users with disabilities. In the case of CSUN’s Center on Disabilities, one of CSUN Open Journals partners, this lack of compliance is a deal breaker. The COD is unlikely to use OJS with Oviatt Library beyond the front-end capacity. Since peer-reviewers, editors or other staff affiliated with the COD's conference and journal may have need of fully accessible software. It is argued, however, that most of these errors can be easily fixed. Once such issues are addressed, it is likely that CSUN Oviatt Library will continue to use OJS to develop viable open access journals for all its constituents. CITATIONS: Anon., 2014. California State University Accessible Technology Initiative FAQ. [Online] Available at: http://www.calstate.edu/accessibility/webaccessibility/web_accessibility_FAQs.shtml (Accessed 4 February 2014). Biondo, M. and Weiss, A. (2013), "The California Geographer and the OA movement: using the green OA institutional repository as a publishing platform," in Brown, A. (Ed.), Library Publishing Toolkit, IDS Project Press, Geneseo, NY, pp. 207-214. Cassner, M., Maxey-Harris, C. & Anaya, T., 2011. Differently Able: A Review of Academic Library Websites for People with Disabilities. Behaviorial & Social Sciences Librarian, 30(1), pp. 33-51. Comeaux, D. & Schmetzke, A., 2013. Accessibility of Academic Library Websites in North America: Current Status and Trends (2002-2012). Library Hi Tech, 31(1), pp. 8-33. Cowan, S. (2013), “Open Access Journal Incubator at University of Lethbridge Library”, in Brown, A. (Ed.), Library Publishing Toolkit, IDS Project Press, Geneseo, NY, pp. 179- 186. FAE (2014), Functional Accessibility Evaluator 1.1, [Online]. Available at: http://fae.cita.uiuc.edu/ (Accessed 16 April 2014). Mozilla Foundation. Fangs Screen Reader Emulator: Add-ons for Firefox, [Online]. Available at: .https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader- emulator/ (Accessed 16 April 2014). MacGregor, J. (2010), “Re: OJS and screen readers”, PKP Support [online discussion forum], available at http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility# wrap (accessed 30 January 2014). MacGregor, J., Meijer-Kline, K., Owen, B., Stranack, K. and Willinsky, J. (2013), “The Public Knowledge Project: Open Source-Publishing Services for Your Library”, in Brown, A. (Ed.), Library Publishing Toolkit, IDS Project Press, Geneseo, NY, pp. 359-366. Newton, M., Cunningham, E. and Morris, J. (2013), “Emerging Opportunities in Library Services: Planning for the Future of Scholarly Publishing”, in: Brown, A. (Ed.), Library Publishing Toolkit, IDS Project Press, Geneseo, NY, pp.109-118. “OJS and Screen Readers”, PKP Support [online discussion forum], available at: http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility# wrap (accessed 30 January 2014). WebAim (2014), WebAIM: Web Accessibility In Mind [Online]. Available at: http://wave.webaim.org/ (Accessed 16 April 2014). W3C World Wide Web Consortium (2013), “Understanding WCAG 2.0”, available at: http://www.w3.org/TR/WCAG20/ (Accessed 02 February 2014). http://fae.cita.uiuc.edu/ https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/ https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/ http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility#wrap http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility#wrap http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility#wrap http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility#wrap http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility#wrap http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=3048&p=10931&hilit=accessibility#wrap http://wave.webaim.org/ http://www.w3.org/TR/WCAG20/ http://www.w3.org/TR/WCAG20/ About the Authors: Laurie Borchard is a Digital Learning Initiatives Librarian at California State University, Northridge; she can be reached at laurie.borchard@csun.edu. Michael Biondo is the ScholarWorks Assistant at California State University, Northridge; he is a graduate student in the School of Library and Information Science at San Jose State University. Stephen Kutay is a Digital Services Librarian at California State University, Northridge. David Morck is a Web Programmer at California State University, Northridge. Andrew Weiss is a Digital Services Librarian at California State University, Northridge. mailto:laurie.borchard@csun.edu Structured Abstract: I. Project Overview II. Background: Accessibility, Open Access publishing & accessible software design III. Methodology IV. Results V. Discussion: Implications and quick fixes VI. Future Studies, Limitations and Conclusion CITATIONS: About the Authors: