Intro to Accessible HTML

Transcript

[HTML]

So starting with HTML. Broadly, we want to start with resize and reflow. Just design your websites mobile first and responsively. You never want to disable scalability at the site level. This is going to ensure that all of the text on your website is still visible and legible when it’s zoomed in up to 200%. Containers should flow around text so that nothing is obscured. Also, you want all the content to fit on your screen without horizontal scrolling when zoomed in to about 400%.

When a user zooms in to 400%, it’s basically equivalent to viewing the page on a phone or mobile device at a width of 320 pixels. So basically, if your design supports mobile device viewing without requiring horizontal scrolling, it’s going to accommodate 400% zoom and satisfy that WCAG criteria. Layouts in general should also not require horizontal scrolling with a few exceptions where it’s necessary like maps and large data tables. So for the HTML snippet here, just want to point out the meta name. Sorry, the meta name attribute for your content, you would want to set it to width equals device width. And initial scale is equal to 1. You do not want to set the content to user scalable equals no.

OK, page language and language changes. You also want to specify the language of your page in the HTML attribute at the top. So for example, HTML language equals EN for English. This allows screen readers to programmatically determine which language to read aloud and ensures correct pronunciation. If you don’t specify it, a screen reader will try and make its best guess as to what language the pages in and it doesn’t always come out right. If you also have elements on the page that appear in a language other than the page’s main language, such as a section in French, you can just wrap them in span tags or the container element and specify the language that that snippet will be in. So for example, span language equals FR for French and then Français and closing span tag.

Navigation and landmarks. You want to structure your site with semantic landmarks. So preferably you could use native HTML5 elements such as header, nav, main, footer, and so on. This will allow screen reader users to quickly skip through to various sections of the page. HTML5 landmark rules are preferable. But if you are using non HTML5 region elements like div, you can use ARIA landmark roles such as role equals navigation and role equals main. We’ll get a little more into that in the next training Intro to ARIA.

You also want to keep navigation consistent across your site. When the order of repeated content is predictable, this helps users locate elements and navigate your site quickly. Also, it’s a good idea to include a Skip Navigation or Skip To Main Content link at the top of your site. Because this allows users to jump straight to the main content without having to interact with the navigation on every single page.

So you can see on the left, I have bolded the main content link down to the ID of main content on the main navigation. Or sorry, or landmark element. And then I also have an example of a div with the role equals main.

Focus order and parsing. Your DOM order should match the visual order. If you organize interactive elements logically, you can preserve meaning and structure when they’re being tabbed through. And if your content is being added dynamically to the DOM, make sure to place it immediately after the triggering event so that when a screen reader is going through the content, it doesn’t miss anything and it presents it all in a logical order.

You want to make sure you write proper semantic code with start and end tags, nesting elements according to specification, keeping IDs unique, and don’t duplicate attributes.

Title tags and attributes. Always include a title tag in your head section. The title order should be from most specific to most general, such as page title, and then maybe a pipe and site title. So for example, Admissions, pipe, the University of Chicago.

All iframes should also have a title attribute. Ensure that the iframe’s title attribute is meaningful and descriptive so that context– screen reader users have context when they get to it. Also, just be mindful about using title attribute for tooltips. That information will not be accessible to a keyboard only user or a screen reader user. So any important information about how to interact with an element that you might consider putting in a tooltip is better to be put on the page. Also note that the title attribute is not equivalent to an ARIA label. So assistive technologies will ignore it. Oops.

Headings. Screen reader users can jump from heading to heading on a page. So you want to design your content to fit into logical heading structures and always use the semantic heading tags so, H1 through H6, rather than styled paragraph tags. Make sure that your main page title is in H1 so that a screen reader user knows what to expect on that page. And in terms of CMS templates, to the extent that you can control it, try to make sure that all the H tags that appear on a page are ordered properly and avoid skipping heading levels.

Link attributes. All anchor tags must include an href attribute even if the link doesn’t go anywhere in order to be properly recognized by a screen reader. You also want to avoid using links and buttons interchangeably. So buttons should be used for clickable actions and links should take you to another page. Links and buttons have different keyboard activation commands. So that can cause a lot of confusion for a screen reader user if you’re using them interchangeably or where they shouldn’t be used.

Lists. Some assistive technologies allow users to jump from list to list. And the screen readers will announce ordered an unordered list to the user allowing the user to understand the relationship and structure of the information presented. So you want to make sure you use the list types appropriate for their purpose, such as OL ordered list for numerical, and unordered lists, UL for bullet points. For content owners, make sure you just provide a means for them to format lists correctly so that you discourage users from just typing in one period space whatever.

Images and alternative text. Provide a way in the CMS, or admin tools, for a content editor to input meaningful alt text on images. The alt text was presented to screen reader users in place of images 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. There is actually a surprising amount of nuance to when you should use alternative text. The exceptions are decorative images, which should have empty alt text, but should also still use that attribute of alt equals open close quotation marks with no space. Or you can place the image using CSS.

If it’s a logo, it should follow the format of the name of company logo. So for us, it would be the University of Chicago logo. And if your image is linked, the alt text should describe the destination of the link and give a meaningful explanation of where the user should expect to end up.

For tables, as I’m sure you all know, tables should be used for presenting tabular data only and not layout or design. Some assistive technologies allow users to jump directly to them.

And tables with improper semantic markup will be really difficult, if not impossible, for a screen reader user to understand. So always make sure to identify row and column headers with the TH tag rather than styled TD. You want to associate table header cells with a column or row using the scope attribute. This allows the screen reader users to read out all data associated with the header cell. So you can see on the left, I’ve got the first row in the T head, all of those TH cells have a scope of column. But also in the body, I have the first cell is a TH again with a scope of row. So a screen reader user would be able to understand that that is acting as the header cell for everything in that row.

Also, if your table has a description, you could include it as a caption in the caption tag. These aren’t required for accessibility purposes. But it can be very helpful for a screen reader user to understand the purpose of the table.

Let’s talk about forms starting with form labels. All form input should have an associated label. You want to clearly associate the form names and labels with input elements and input groups, both visually and programmatically. You also want to avoid having too much visible space between labels and fields so that users with cognitive disabilities will be able to visually understand that those two pieces are connected together. Ensure that all your labels are descriptive. And visible form– excuse me. Visible form labels are preferable. But at minimum, all labels should be programmatically associated. So if the label is visually hidden, you can use aria-label and aria-labelled by to provide additional information for screen readers.

So I’ve got as an example on the left in the top section, we have using the label element for equals name and then associated the input element of ID equals name. On the bottom, we’ve got the label wrapped in a div. So we have associated ID name2 on that label with aria-labelledby equals name2.

Required form fields. You want to be sure to identify them. If your form has a mix of required and non required fields, add either the HTML5 required attribute, or aria-required equals true to each input that is required. This helps identify them as required to screen reader users.

And inputs. Use the autocomplete attribute for certain common inputs like name, username, and password, et cetera. This helps user agents and assistive technology provide personalized presentations to help the user more easily understand the purpose of the field. So you can see on the left, I’ve got input for a username. And I have autocomplete equals username. You could find a list of what autocomplete attributes exist online.

Screen readers will be able to– I’m sorry. Screen readers will read the value attribute of an input button and the text between button tags. So if input type is equal to submit, the value submit data will be what is read out to by a screen reader. And a button will be the text between the button tag. So button, press this button, close button tag.

If the visible text in the button tag is not meaningful without context, for example, if you want an X to close a dialogue, you want to add a meaningful and descriptive ARIA label. So here we’ve also got an example of button with an ARIA label of close. And the visible text is an X.

[CSS]

Moving on to CSS. Focus indicators. Any element that can receive focus, which is a link, button, custom interactive control, stuff like that, they should all have a visible focus indicator. Usually, this just means that by default, you have an outline surrounding the element in focus. It’s typically a blue box. As you can see on the left, I have a screenshot of some dummy text with a couple of links. And the first one is in focus with a blue box around it.

Don’t deliberately hide or remove the default focus indicator with CSS. If you do choose to customize it, just be mindful of maintaining at least a 4.5 to 1 color contrast ratio against the background color. So if you’re customizing it to, say, a maroon box, you want to maybe change that color if you’ve got it against a black background.

And speaking of color and color contrast, you want to avoid using color alone to convey meaning. So for example, on a form, you don’t want to use red alone to visually indicate required fields or errors. Use a symbol, like an asterisk, or the words required, or error. You can also make them red if you want. But you want to make sure that people who maybe are color blind will still be able to understand the information you’re trying to convey.

Use sufficient color contrast. Body text and links should have a minimum of 4.5 to 1 contrast ratio at the background. And for hyperlinks, color alone is almost never sufficient to distinguish the link from the surrounding text. Because the link color not only has to have proper contrast with the page background, but also a 3 to 1 contrast with surrounding text. If these requirements can’t be met, links should be styled with a secondary visual indicator such as an underline or bottom border. There are actually only 26 web safe color combinations that are compliant without additional indicators. And chances are your design is not using one of those colors. So be sure to check your colors with online checkers such as WebAIM’s link contrast checker.

That tool will allow you to put in the color of your link, your surrounding text, and the background. And it will tell you if it passes contrast requirements. So for us, the UChicago maroon with a hex value of 800000, it does have a passing contrast of 10.94 to 1 against a white background. But next to black text, it has a failing ratio of 1.91 to 1. So we always recommend that UChicago websites should add an underline or a bottom border as additional decoration and means of identification for links.

Another cool thing that’s relatively new in CSS is the media query of prefers-reduced-motion. Many operating systems have an accessibility setting for reducing or removing animation in motion. If you use the prefers-reduced-motion media query, you can provide alternate styles for elements without animation for users who have the setting enabled. So this just looks like any other media query, @media prefers-reduced-motion reduce if the user has that setting enabled. And then you can put in your CSS that does not include any animation effects.

Otherwise, @media prefers-reduced-motion no preference. Include whatever CSS animation you want.

[Content and media considerations]

Some content and media considerations. Let’s revisit links. You want to work meaningful link text into your design. If templated layouts call for repetitive design elements such as news cards, consider linking the title instead of using repetitive phrases such as read more, or click here. This is going to help screen reader users because they can jump between links on a page.

And link text should be specific, clear, and ideally should match the title of the page to which you’re linking so that they can understand the destination out of context. It’s also– excuse me, also helpful for sighted users who might be scanning the page quickly to see where they might be able to go from there. They’re going to get a lot more information from seeing the link’s title than just phrases that say, click here, click here, click here.

But if, however, repetitive phrases like read more are unavoidable, you want to use a descriptive ARIA label on the anchor tag to describe the link destination to screen reader users. The ARIA label will override the visible link text so that a screen reader user is just going to hear what’s in the ARIA label. Include the visible link text in the label and provide a means in the CMS for content owners to update that ARIA label.

So here, I’ve got a couple of examples of just the basic anchor tag with the visible text the University of Chicago, and then another version where the visible text is read more. And it just has an ARIA label of read more about the University of Chicago.

Time based media. This includes audio, video, slideshow, and animation. Provide pause, stop, or mute mechanisms independent of system audio for any audio that plays automatically for more than three seconds.

Audio can interfere with the user’s ability to hear or understand their screen reader. You also should provide pause, stop, or hide mechanisms for any moving, blinking, scrolling, or auto updating content that lasts more than five seconds. So carousels, videos, that sort of thing. Moving content can be a barrier for users who have difficulty reading text quickly, users who have trouble tracking motion. It’s actually pretty challenging to successfully design moving content to be fully accessible. And moving content is often very challenging for screen reader users to navigate.

It can also pose a severe distraction to some users, particularly people who have attention deficit disorders, and can be very difficult for people with any motion sensitivity that can cause nausea. So you want to use moving videos sparingly, or at the very least provide means to easily pause or stop them. Also you should design content in a way that’s not known to cause seizures or physical reactions. WCAG success criteria 2.3.1 states that web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

[Test it!]

And finally, test it. We’ll get into more detailed testing in the training about how to test for accessibility. But I’m just going to put in a plug for testing it with a keyboard. This is one of the easier tests you can do. Just test your website by navigating it with only a keyboard. Anything that you can do with a mouse should also be doable with a keyboard. So if you’re using styles or events such as hover, on mouse over, on mouse out, be sure to provide alternative interactions for keyboard only users with focus, on click, et cetera.

When you’re testing with a keyboard, you can navigate with tab, which moves you to the next interactive element like links, buttons, form controls. Shift Tab takes you backwards. Return or Enter will activate elements like links and buttons. Space toggles element state, such as pause, play, checkbox, combo box, et cetera. Escape should close any open content like menus or modals, or cancel an action. And arrow keys change the value of items and combo boxes, radio button groups, et cetera, or scrolls the viewport up and down.

If you can’t successfully navigate your website with a keyboard, that should tell you to go back and fix that so that it is interactive with a keyboard. Pay particular attention to search bars and sub menus. Those very frequently are activated by just hover. And so and you never want to rely on hover alone.

If an element is meant to be hidden and non intractable, conversely, you want to make sure it’s also hidden from keyboard users and screen reader users with properties like display none or visibility hidden. It can be very confusing and disorienting if a keyboard user or screen reader user ends up on an element that isn’t meant to be there for– isn’t visually meant to be there and with no context of how they ended up there.

[Conclusion]

So that’s it. Are there any questions? Yeah, so if you do have any questions, feel free to contact us. We’re here to provide digital accessibility resources for campus. You can email us at digitalaccessibility@uchicago.edu and that will reach the whole team. You can also find resources for content owners and developers on our website, which is digitalaccessibility.uchicago.edu. Thank you for your time.