Frequent perceivability errors and suggested corrections
Common errors
Level-A 1.3.1 information and relationships errors (N = 17,564) comprised the largest percentage of all errors in this study (39.7%). The W3C defines this guideline as “Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text” (Accessibility Principles, 2019). These errors are related to the underlying structure of the text on a webpage and whether students with a wide range of disabilities who use screen readers can easily understand the content. In our study, we identified three common error types Tenon identified as aligned with this guideline: implicit headings, all capitalized sentences, and multiple strategies used to create the labels. Implicit headings are sections of content that are bolded, possibly indicating a heading. Similarly, the second most common error aligned with this guideline was having large sections of text that are all capitalized. For example, many Level-A 1.3.1 errors identified web elements with overly long passages of text (ten or more words) in bold and/or uppercase letters. Although using bold and uppercase text may be beneficial for some web users, this formatting may be difficult to read and comprehend for students with dyslexia, for example. Sections of text that are bolded and/or in uppercase can imply a heading in the text. However, to interface with screen readers, HTML headings must be used.
Another common error aligned with WCAG Level A 1.3.1 was related to using multiple strategies to create labels. Specifically, multiple methods were used to create the same label on the webpage. For example, our sample included an institution whose associate’s degree in physics curriculum webpage included a fillable form that used Cascading Style Sheets (CSS) to generate multiple labels for the fields within that form. CSS is generally used for defining the styling of a web page, such as colors and sizes of elements, but it also has the ability to insert content into the page. Either function has the possibility of creating accessibility barriers. Often, web developers will use visual elements to label form fields for sighted users and visually hidden HTML elements to label form fields for screen reader users. Having multiple labels for the same field allows opportunities for the labels to be repetitive or different from each other, since there are multiple places where the labels need to be updated, which could cause confusion for the user. In addition to 1.3.1, the multiple strategies to create labels error is aligned with standards 1.1.1, and 4.1.2. Many form fields are non-text, meaning that they need a text-based alternative, such as a form label, aligning with 1.1.1. For example, an empty form field (i.e., place for user to input information) does not have any text for the user; so, a form label can be added to inform the user how to interact with the web element. Also, form fields are user interface components (i.e., part of the webpage that the users interact with) and must adhere to all success criteria outlined in 4.1.2.
Level-A 1.1.1 non-text content errors (N = 11,965) comprised 27.0% of all web accessibility errors in this study. Non-text content errors occur when a non-text web element (e.g., image) is missing information to communicate with the assistive technology that a student with a disability may use to navigate the webpage. We identified three common error titles that Tenon aligned with this standard: the presence of non-text content created using cascading style sheets (CSS), uninformative text description of non-text information, and, similar to Level A 1.3.1, having multiple strategies to create a label.
Content styled with CSS can create accessibility issues for both sighted and screen reader users. For example, our sample included an institution whose bachelor’s degree in physics curriculum webpage used CSS to generate content that appeared to be hyperlinked but was not. In this case, the CSS generated a word that was underlined but was not a hyperlink, possibly confusing students as to why the word was underlined or why it did not lead to a different webpage when underlined words in web content generally indicate hyperlinks. Additionally, many images were delivered via icon font, which may not be accessible via assistive technology. Thus, when screen reading software interacts with the non-text element, it reads the name of the font rather than a description of the content presented in the element.
Level-A 1.4.4 resize text errors (N = 4436) comprised 10.0% of all errors in this study. These errors pertain to the size and position of text on a webpage. Nearly all resize text errors in this study arose from font that was too small on the webpage for web users who have low vision. In some instances, the font on webpages was at 8 pixels or smaller, making it very difficult for most web users, and especially those with low vision, to read the text. The default font size in most web browsers is set to be 16 pixels. Another error Tenon aligned with this WCAG standard is that an element used absolute positioning. An element that is absolutely positioned can cause difficulties with zooming in on the webpage as the element has a set position rather than a position defined relative to another element on the webpage. If web users must zoom in to read the font, other content on the webpage may become distorted, leading to confusion.
Suggested solutions
Many of the Level-A 1.3.1 errors in this study could be fixed by adopting two approaches. First, using HTML to communicate headings rather than bold or uppercase text would improve the readability of text on the webpage. Second, explicit labels for each form field should be defined in HTML and then styled using CSS, accurately informing the user of what information belongs in the form field while achieving the desired design and avoiding duplicate form field labels. Writing appropriate HTML requires deeper knowledge of programming, so web administrators should be involved in this process.
Many of this study’s Level-A 1.1.1 errors could be fixed by ensuring images and icons are presented with text-based equivalents and avoiding CSS-generated content. Level-A 1.4.4 errors could be fixed by increasing the size of webpage font and by using relative positioning of elements.
Frequent operability errors and suggested corrections
Common errors
Level-A 2.4.4 link purpose web errors (N = 6514) comprised 14.7% of all web accessibility errors in this study. The W3C describes this standard as “The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general” (Accessibility Principles, 2019).
Level-A 2.4.4 errors were identified for redundant hyperlink destinations with different hyperlink text, meaning hyperlinks with different link texts lead to the same webpage. Redundant hyperlink destinations may be confusing for students with disabilities, as a web user may expect that hyperlinks with different descriptive text lead to different webpages. Many other Level-A 2.4.4 errors identified uninformative hyperlink link texts (an informative description of the content pertaining to the hyperlink and where a user will go if they click on the hyperlink), including link text such as “link” and “link to page”. These link texts are not informative enough for students with disabilities. For example, a student with low vision may navigate through a webpage using the tab key and may jump from one element type to another (e.g., links, buttons, form fields). When they land on a link, the link text will be read out loud. If the link text is informative, the link will make sense without the user having to explore the surrounding text for context. Instead, content editors should provide rich link texts of hyperlinks (e.g., “physics curriculum webpage” instead of “link”), so that students with disabilities are given enough information to successfully navigate the webpage and find the content they need.
Suggested solutions
Many of the Level-A 2.4.4 errors could be resolved by making sure that all hyperlinks include unique, informative link texts and that multiple hyperlinks with differing link texts do not lead to the same webpage. As a result, users will know exactly what content the hyperlink pertains to and exactly where the hyperlink will lead them when clicked.
Frequent robustness errors and suggested corrections
Common error
Robust Level-A 4.1.2 name, role, and value errors were abundant (N = 4937) and comprised 11.2% of all web accessibility errors in this study. The W3C states that the intent of Level-A 4.1.2 is to “ensure that Assistive Technologies (AT) can gather information about, activate (or set) and keep up to date on the status of user interface controls in the content” (Accessibility Principles, 2019). Errors in our study that aligned with this success criterion were related to a webpage having an invalid hypertext reference and related to orphaned Accessible Rich Internet Application (ARIA) attributes. Href stands for “hypertext reference” and is information that specifies the URL of the webpage that the hyperlink goes to. This likely corresponds to a webpage including a link to scroll to the top of the webpage rather than to redirect to another webpage (i.e., HTML that reads href=“#”). This type of href makes the link confusing when interfacing with the webpage via an assistive technology. In addition, many Level-A 4.1.2 errors identified “orphaned” ARIA attributes. ARIA attributes are additional pieces of information that communicate with assistive technologies, informing the user about what kind of web elements are on the webpage and how to interact with the elements. In this case, “orphaned” ARIA attributes are attributes that depend on a previously defined ARIA attribute or parent attribute; however, the parent attribute does not exist.
Both href and ARIA attributes of hyperlinks are important when a wide range of assistive technologies attempt to communicate with web elements on a webpage and they mark up the webpage to give cues to the user about the interface. Additional information about when to use and not use ARIA attributes is described by the W3C (World Wide Web Consortium, 2018). However, the W3C states: “no ARIA is better than bad ARIA” (World Wide Web Consortium, 2019c) so the implementation of ARIA in a webpage should be done in concert with webpage design experts.
Suggested solution
Level-A 4.1.2 errors require more extensive knowledge of markup language (e.g., HTML, JavaScript), so they should be addressed by web administrators and developers working at institutions of higher education to ensure that each institutional webpage includes the most robust and informative information to allow the widest range of assistive technologies access to the content. As Level-A 4.1.2 errors primarily address content developed by the web administrator, these errors are most prevalent when web elements are developed but under described, such as the case of missing href or ARIA attributes. It takes more technical skill to accessibly generate complicated web elements; thus, physics departments should strive to create webpages using simple web elements.
Other errors with simple solutions
One perceivable Level-A 1.2.2 captions (prerecorded) error was identified in this study. This error indicates that a video was not captioned, making it difficult for web users who are deaf to access the content (e.g., requiring them to use additional resources, such as a sign language interpreter). All video content should be captioned.
Understandable Level-A 3.1.1 language of page errors (< 1% of all errors) indicate that the spoken language of the webpage (i.e., “en” for English) was not included in the language attributes of the web element. In this case, a screen reader interfacing with the webpage will not know what language it is reading and may mispronounce words. Moreover, a student with a disability who is an English language learner may not be aware that the webpage contains multilingual content. The language used on a webpage should be identified in the attributes of the web element.
Operable Level-A 2.1.1 keyboard errors (1.4% of all errors) indicate that many web elements were not written in ways that allow keyboard-centric assistive technologies access to the content. For example, some users exclusively use a keyboard to navigate a webpage while others use alternative keyboards. Although Level-A 2.1.1 errors involve many different aspects of web accessibility, it is important to note that keyboard-centric assistive technologies are widely used by people with disabilities when accessing webpages. Physics curriculum writers and institutional web developers should pay close attention to whether their webpages can be used with a keyboard alone without requiring the use of a mouse. Professionals interested in improving the web accessibility of their webpages could look to WebAIM’s website, published specifically to educate people who wish to improve their web accessibility and provide more inclusive and robust online information for people with disabilities.
Overall, the findings of this study are in line with findings from previous studies. Specifically, many web pages in higher education do not align with the WCAG guidelines (Erickson et al., 2013; Forgione-Barkas, 2012; Kimmons, 2017; Solovieva & Bock, 2014; Thompson et al., 2010). Multiple studies similarly identified a significant lack of meaningful description for images (Hackett & Parmanto, 2005; Krach, 2007; Thompson et al., 2010) which aligns with our finding of many 1.1.1 Level-A errors. Prior investigations (see McGough, 2016 for a summary) also identified accessibility issues related to skip navigation and effective keyboard navigation. These two issues were not commonly identified as errors in this study.
Limitations
This study focused on one facet of accessibility present in the postsecondary learning environment (i.e., web accessibility). However, there are multiple aspects related to accessibility that were beyond the scope of this study, including (1) the accessibility of physics curricular content (which we previously investigated in Scanlon et al., 2018b); (2) on-campus living space; (3) the social interactions between students with disabilities and their instructors and peers (which we previously investigated in James et al., 2019); (4) the relationship between the local disability services office, instructors, and students with disabilities; and (5) attitudes and beliefs of instructors and university staff (which we previously investigated in Scanlon & Chini, 2019). All aspects of accessibility can affect how a student with disability interacts with the learning environment and their success in the program of their choice.
This monostrand conversion mixed methods study focused only on webpages in the USA related to undergraduate physics curriculum and graduate research opportunities, and our sample did not include any private, for-profit institutions. Additionally, our sample was limited to 6% of title IV-participating institution in the USA.
Moreover, this study was limited by the evaluation of web accessibility using a single accessibility audit software and one assistive technology. The WCAG standards have been criticized for being screen reader-centric and for not including success criteria for people with cognitive impairments (Clark, 2006). More information about the work the W3C is doing to support people with cognitive impairments for next iterations of the WCAG standards can be found on their website (World Wide Web Consortium, 2019b). In addition, the chosen accessibility audit software did not check for time-based media (i.e., audio or video) described in WCAG 2.0 Standard 1.2. Because our analysis and proposed suggestions are aligned with specific WCAG 2.0 standards, our proposed suggestions will be similarly screen reader-centric. Given the time-intensive nature of data collection and analysis, the research team decided it was only feasible to evaluate the webpages using one audit software and one assistive technology, understanding that webpages often change on a daily or hourly basis. In addition, this study only analyzed HTML content of webpages and not other documents, such as PDF files or PowerPoint presentations.
As a result, future research could expand upon our sample size, use a greater number of accessibility audit software programs and assistive technologies, audit specific courses in physics curriculum, expand the number of WCAG standards investigated, and employ a larger research team to provide a more comprehensive picture of the web accessibility of physics curriculum webpages at US institutions of higher education. Additionally, future research could address other webpages students must interact with to navigate postsecondary education, such as financial aid, student affairs, and Title-IX webpages.