Accessibility for Designers and Developers

Transcript

Hello and welcome to Accessibility for Designers and Developers. This session is recorded in December of 2020.

Hi. I’m Thalia Kapica. I am a Certified Professional in Accessibility Core Competencies, known as CPACC. I’m the Senior Accessible Web Technology Specialist in the Center for Digital Accessibility, in IT Services. My email address is kapica@uchicago.edu.

A little bit about me. I’ve been at UChicago since 2012. Previously, I was the Web Operations Manager slash Lead Web Developer in College IT. I joined the CDA—Center for Digital Accessibility—in January of 2020, which is when the CDA started.

Little bit about the CDA. The UChicago Center for Digital Accessibility provides digital accessibility consulting, assessment and training for students, faculty, other academic appointees, staff and postdoctoral researchers at the University of Chicago.

[Why be Accessible?]

So why be accessible? About 25 percent of people identify as having some kind of disability. Disabilities that can affect digital use include auditory, such as deafness or hard of hearing; cognitive, such as dyslexia, attention deficit disorder and learning disabilities; motor control, like arthritis and muscular dystrophy; neurological conditions, such as epilepsy and migraines; speech impairment; visual, such as blind, visually impaired or colorblind, and also temporary conditions like a broken arm, or you’ve just had eye surgery; or situational conditions, like varying screen size, a bright light on your screen or if you’re in loud surroundings.

So how do people with disabilities navigate websites? Users with disabilities often employ assistive technology to interact with digital content, including websites. Some examples of assistive technology include screen reader software, pointing devices, alternative keyboards including refreshable Braille keyboards, eye gaze tracking technology and voice recognition software.

So what standards does the University use? Well, we use WCAG 2.1 Level AA. These are international standards of the World Wide Web Consortium’s Web Content Accessibility Guidelines, also known as WCAG. They’re recognized best practices for public-facing websites. WCAG 2.1 guidelines are organized according to the four principles of accessibility, which maintain that web content must be perceivable, operable, understandable and robust. You can learn more about WCAG 2.1 on the W3C’s website.

[Designing for Web Accessibility]

So let’s start with designing for web accessibility. “Great web accessibility starts in the design.” This is a quote from WebAIM, which is a great online resource for accessibility techniques. I’ve included an infographic that covers key points in web accessibility for designers. I won’t read out every item on the list, but I will cover a number of them in the following slides.

Heading order. This falls under WCAG Success Criterion 1.3.1 Info and Relationships. Screen reader users can jump from heading to heading on a page. Design your content to fit into logical heading structures. Use properly formatted heading structure to organize your page and be sure to make your main page title, which is typically the big, bold text at the start, an H1 to facilitate page navigation and comprehension. Avoid also skipping heading levels. So, for example, your H1 would be a page title, your H2 would be a subsection, and under that subsection you might have a couple of H3s. And then you might have another H2 subsection with further H3s below that.

Use of color and color contrast. This is WCAG Success Criteria 1.4.1 Use of Color and 1.4.3 Contrast (Minimum). Avoid using color alone to convey meaning. For example, do not use red alone to indicate required fields for errors on a form. Use a symbol such as an asterisk or the word “required.” Also use sufficient color contrast. Body text and links should have a minimum 4.5 to 1 ratio with the background. For hyperlinks, the color must also have sufficient color contrast not only with the background, but with the surrounding text as well. These hyperlinks have to have a sufficient 3 to 1 color contrast. And if it doesn’t, it should be accompanied by a visual indicator such as an underline or a bottom border.

Keep in mind that there are only 26 web-safe color combinations that are compliant without additional indicators. This means that it’s very likely in your design you’re going to want to add another visual indicator. There are many online tools where you can check your colors. One of the ones that we recommend using is the WebAIM Link Contrast Checker, which can be found at webaim.org/resources/linkcontrastchecker.

So for an example of color and color contrast in use, the official UChicago maroon color, which has hex value 800000, does have a passing contrast ratio of 10.94 to 1 against a white background. But next to surrounding black text, its ratio is only 1.91 to 1. Therefore, for UChicago websites, we recommend an underline or a dotted border to provide that additional means of identification as a link.

And here I have a couple of screenshots for examples. The first screenshot is from the Programs of Study page on the College website. The link phrase “core curriculum” is colored in maroon and has a solid underline. The second screenshot is from the Web Accessibility page on the UChicago Website Resource Center. Here the link phrase “color contrast” is also colored in maroon, but styled with a dotted bottom border.

And speaking of link phrases, use meaningful link text. This is WCAG Criteria 2.4.4 Link Purpose (In Context). You want to avoid ambiguous link text such as “click here” and “learn more” as well as avoiding long URLs, especially ones that are ugly with lots of symbols in them. Link text instead should be specific, clear and ideally should match the title of the page to which are linking. In other words, a user should be able to understand the phrase out of context. Screen reader users especially can jump from link to link on a page. And they should be able to understand where that link will take them just by hearing the phrase.

For design elements such as news items were a repetitive phrase like “read more” is visually preferable, you can use a descriptive ARIA label on the anchor tag to describe the link destination instead. And when linking to a document, you should also include the format in parentheses that users will know the format before following the link. For example, you would have “document title, open parentheses, PDF, close parentheses.”

Here I have another screenshot as an example of how to use meaningful link text in an ARIA label. This screenshot is from UChicago Alumni & Friends and it shows a number of events for which a user can get event info or register. I have the web inspector open, highlighting one of the register buttons, and you can see in the inspector the code on the button allowing users to register for this event has an ARIA label that says “Register for event: alumni coffee and conversations, December 4th.”

Alternative text on images, Success Criteria 1.1.1 Non-Text Content. Alternative text is presented to screen reader users in place of images that they may not be able to see. Every image that conveys content or has a function on your website should be given meaningful alternative text. There are some exceptions to this, such as decorative images, which should have empty alt text, which would be alt equals open and close parentheses with no space, or simply be placed using CSS. Logos should follow the format “name of company, logo” and linked images should describe the destination of the link using meaningful link text instead of what the image itself visually looks like.

When you’re building websites, provide a means for your content owners to add alt text to images.

Some tips for good alt text are to describe the content and function of the image; to be succinct, which is roughly the length of a tweet, and do not use phrases like “image of” or “picture of.” Screen readers will announce that it is an image. Also in your design, you should avoid images of text. Any text content should be on the page. If this can’t be avoided, make sure to also provide the same information in a text format.

Time-based media, including audio, video, slideshow and animation. Success Criteria here are 1.4.2 Audio Control, 2.2.2 Pause, Stop, Hide, 2.3.1 Three Flashes or Below Threshold. Provide pause, stop or mute mechanisms independent of system audio for any audio that plays automatically for more than three seconds. You should also provide pause, stop or hide mechanisms for any moving, blinking, scrolling or auto-updating content that last more than five seconds. This includes videos and slideshows, something that might automatically play when you load a web page.

Design content in a way that is not known to cause seizures or physical reactions. Here I have a quote from the WCAG 2.3.1 guidelines that says, “Web pages do not contain anything that flashes more than three times in any one second period, or the flashes below the general flash and red flash thresholds.”

Continuing on time-based media: transcripts. This is WCAG Criteria 1.2.1 Audio-only and Video-only (Prerecorded). A transcript is the text version of media content. A transcript for prerecorded audio-only or a transcript or audio track for prerecorded video-only content is required. And make it easy for users to find the transcript. For example, you might want design space to put the transcript itself or a link to the transcript right under the video on your web page.

Note also that transcripts are separate from captions, which must also be provided. Captions are a text version of the speech and non-speech audio information needed to understand audio and video content. They’re displayed within the media player and are synchronized with the audio.

Easily identifiable interactive elements. WCAG Criteria 2.4.7 Focus Visible. Any element that receives focus should have a visible focus indicator both on mouse interaction and keyboard interaction. This is often a blue box surrounding the element in focus. Typically, this means not hiding or removing the default focus indicator provided by browsers. If in your design you do want to customize focus indicators, be mindful of maintaining that 4.5 to 1 color contrast ratio with background colors.

[Coding for Web Accessibility]

Coding for Web Accessibility.

Page language and language changes. WCAG Success Criteria 3.1.1 Language of Page, and 3.1.2 Language of Parts. Specify the language of the page in your HTML attribute. For example, HTML lang equals EN, where in this case, EN equals English. You should also specify the language for individual elements on the page that appear in a language other than the page’s primary language attribute. So if you have a section of content that is, for example, in French, you might include a span tag around it with the lang attribute equal FR. This allows screen readers to programmatically determine which language to read aloud. If there is no language specified, then screen readers will attempt to make a guess, and it’s not always accurate.

Focus order and parsing. 2.4.3 Focus Order, 4.1.1 Parsing. DOM order should match visual order. Organize interactive elements logically to preserve meaning and structure when they’re being tabbed through. If content is added dynamically into the DOM, place it immediately after the triggering event.

Write proper semantic code. Use start and end tags, nest elements according to specification, and keep IDs unique, and don’t duplicate attributes.

Navigation and landmarks. WCAG Success Criteria 1.3.1 Info and Relationships, 2.4.1 Bypass Blocks, and 3.2.3 Consistent Navigation. Use landmark roles such as role equals “navigation” and role equals “main” to allow screen reader users to quickly skip through to various sections of the page. Also, keep navigation consistent across your site. When the order of repeated content is predictable, users can locate elements and navigate your site quickly. Consider also including a “skip navigation” or “skip to main content” link at the top of your site. This allows users to jump straight to the main content of your site without having to interact with the navigation on every page, which can get repetitive.

Test your site with a keyboard. This is Success Criteria 2.1 Keyboard Accessible. Some users are unable to use a mouse and interact with web pages purely through a keyboard. Test your website by navigating it with only a keyboard. Anything that can be done with a mouse must be doable with a keyboard as well. Pay particular attention to search bars and submenus.

Never rely on hover alone to interact with elements. If an element is meant to be hidden and non-interactable, make sure it’s also hidden from keyboard users and screen reader users with properties like display none or visibility hidden.

Resize and reflow. WCAG Success Criteria 1.4.4 Resize Text, and 1.4.10 Reflow. Ensure that all text on your website is still visible and legible when zoomed in up to 400 percent. Containers should flow around text so nothing is obscured. Never disable scalability at the site level.

Design responsively. When a user zooms into a web page by 400 percent, it’s effectively equivalent to viewing the page on a phone or a mobile device. So if you design your site in a way that supports mobile device browsing, without requiring any horizontal scrolling, this will also accommodate 400 percent zoom on a desktop browser.

And speaking of, layouts should not require horizontal scrolling, with a few exceptions where it’s necessary, such as for maps and data tables, where removing horizontal scrolling would result in a loss of data.

Form fields. WCAG Success Criteria 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions, and 4.1.2 Name, Role, Value. Identify required form fields. If your form has a mix of required and non-required fields, add the aria required equals “true” attribute to each input that is required. This will identify them as required to screen reader users who can’t necessarily see the note that it’s required.

Clearly associate form names and labels with fields both visually and programmatically. This means avoiding having too much visual space between labels and fields, and that all form fields should have an associated label. Use the “for” attribute on the label element matched to the form element ID. For example, you might have label for equals “name,” and then “name,” and then close the label. And then on your input element, your ID is equal to “name.” If the label is visually hidden, use aria-label and aria-labelledby.

Lists. WCAG Criteria 1.3.1 Info and Relationships. Some assistive technologies allow users to jump from list to list. Screen readers announce ordered and unordered lists to the user, allowing the user to understand the relationship and structure of the information presented. Use types appropriate for their purpose. This means OL for ordered lists for numerical lists, and UL for unordered lists for bullet points. Provide a means for your content owners to format lists correctly.

Tables. This is also WCAG 1.3.1 Info and Relationships. Some assistive technologies allow users to jump directly to tables. Tables should be used only for presenting tabular data, not for layout or design. Identify row and column headers with the TH tag and associate table header cells with a column or row using the scope attribute, i.e. TH scope equals “col” for columns, or TH scope equals “row” for rows. If your table has a description, include it as a table caption using the caption tag. These aren’t required, but they can be helpful to a screen reader user in understanding the purpose of the table.

[Conclusion]

If you have any questions, please feel free to contact the CDA. We’re here to provide digital accessibility resources for campus. You can email us at digitalaccessibility@uchicago.edu. And you can also find resources for content owners and developers on the CDA website, which is digitalaccessibility.uchicago.edu.

Thank you.