« Return to video

10 Tips for Creating Accessible Web Content with (Updated) WCAG [TRANSCRIPT]

SAMANTHA SAULD: Thanks for joining this webinar, entitled “10 Tips for Creating Accessible Web Content with (Updated) WCAG.” I’m Samantha Sauld from 3Play Media, and I’ll be moderating today. I’m joined today by Janet Sylvia, who has provided web accessibility consultation and training for the past 20 years. Her areas of expertise include accessibility in higher education, Section 508, and the Web Content Accessibility Guidelines, otherwise known as WCAG.

In 2011, Janet founded the Web Accessibility Group for Higher Education, which is now under the auspices of the state of Georgia ADA coordinator’s office. And in 2019, she was recognized by AMAC Accessibility for her outstanding contribution as a leader in the higher education community. She has raised awareness and advocated for accessible education for all, becoming a leading voice in this arena. And with that, I’ll hand it off to Janet, who has a wonderful presentation prepared for you.

JANET SYLVIA: Thank you, everyone. It’s great to be here today to meet with you. This is our agenda for the session. First, we’ll talk about web access for people with disabilities. And then we’ll cover 10 tips for creating accessible web content with the updated WCAG guidelines. And just a note that informative images on the slides will be verbally described.

We’ll begin with web access for people with disabilities. There are four categories of disability types– cognitive– this includes attention deficit disorder, brain injury, dyslexia, language, memory, and reading disabilities– hearing, which includes deaf, hard of hearing, and deaf-blind, motor, which includes arthritis, cerebral palsy, loss of limb, muscular dystrophy, and tremors, and visual, which includes blind, color blind, and low vision.

People with disabilities use assistive technologies. These are products, equipment, and systems that enhance learning, working, and daily living for people with disabilities. These technologies allow people to use their preferred modality to access web content. It may be by hearing, sight, speech, or touch.

We’ll begin with examples of assistive technology for cognitive disabilities. And the first is text-to-speech. And the image on the slide is a web page. The content in the top paragraph is highlighted in yellow. And the text that currently is receiving focus or being read aloud is highlighted in blue. These colors help people with learning or reading disabilities know which section of a web page is currently being read aloud.

Another software is Mind Map. The second image on this slide shows content with information relationships that are mapped out like an org chart. People with cognitive disabilities rely on organization and structure. They’ll often use a site map or a web page, or a table of contents in Word or a PDF document or an online course to understand content.

Examples of assistive technology for hearing disabilities include captions. The first image on this slide is a media player with an arrow pointing to the closed captions. And another is a sign language interpreter. And the second image on this slide is a media player with text, and a second media window is open with the symbol for a sign language interpreter.

Examples of assistive technology for motor disabilities include a mouth stick. The first example is from the website of the Griffin MouthStick Stylus and there is a man who is using a mouth stick to tap out commands on a tablet device. Another device is a speech generator with an eye tracker. This device is from tobiiDynavox. Some people use a speech generator connected to a computer to navigate web content through speech, or an eye tracker using sight to select icons, which represent words or functions, to navigate the web. This particular device has four rows and seven columns of icons to choose from.

Assistive technologies for visual disabilities include– our first image is a Refreshable Braille device. This is a rectangular box with function keys and a row of Braille pens. And when connected to a computer, this device converts web page text into Braille, which the user reads on their fingertips.

The second image is the icon for the JAWS screen reader. This is a text-to-speech translator. JAWS will read aloud text on a web page or other documents. It’s very robust. It can organize content by heading structure and navigate by page titles. It will also aggregate hyperlinks on a web page into a single standalone list. People who use screen readers are keyboard users and they use a keyboard instead of a mouse.

The third image on this slide is a screen magnifier. This is the Dolphin SuperNova Magnifier and Speech. This type of device can enlarge text to over 600% the original size. So individuals who use this magnifier will view only small sections of web content at a time. In this image, the magnifier is displaying three rows of text with three words visible per row. So an individual may view only nine words of text on a web page at any one time.

There are over 20,000 different types of assistive technology. And the question is, how do web designers and developers and academic and online course providers ensure that web-based content is accessible for people with disabilities using different types of assistive technology or using no technology at all? This is done by following accessibility best practices, laws, and guidelines. The primary guidelines are the Web Content Accessibility Guidelines. The acronym, WCAG, is pronounced “wuh-cag,” and the current version is 2.1.

WCAG are international recommendations for making web content accessible for people with disabilities. Now, for legal requirements, you should check with your home country, territory, state, or municipality. In recent years, many countries have harmonized their national or local laws with WCAG. And they now incorporate a reference to follow the current version of WCAG to comply with the legal requirements.

WCAG consists of 78 success criteria at different conformance levels. Level A is the minimum level of accessibility you can achieve using WCAG. There’s level AA. And then AAA is the highest level of accessibility conformance you can achieve using these guidelines. Most groups require conformance with levels A and AA, and so today’s tips are based on some of these criteria.

So next, we’ll go through 10 tips for creating accessible web content with the updated WCAG. Tip number one, accessibility statement. Now, this is a best practice that’s based on legal requirements in some countries, and not WCAG itself. You should include in an accessibility statement the contact name, mailing address, email, and phone number, a statement of conformance– typically, this is provided by your organization. You can check with your accessibility coordinator, disability service provider, equal opportunity office, for example, for existing text that you should use in your statement for your web page or online course– and a response time.

Typically, this is within 24 to 48 business hours of receiving a request. You should respond, acknowledging the request, to let the individual know you are working on their accessibility request. The accessibility statement should be added to your website and your templates– of course, home page, a syllabus, et cetera. The accessibility statement benefits all people with disabilities– cognitive, hearing, motor, and visual. It provides a way for people with disabilities to communicate any questions or concerns that they have about your web-based content.

Tip number two, readability. Ensure that content is readable and understandable. There are many ways to do this. The four that we will discuss today include language, page titles, semantic structure, and text spacing. The benefits here are for people with cognitive, motor, and visual disabilities.

So first, we’ll go through language. And language means that we should designate the primary language for our entire document– an HTML document, Word, PDF, et cetera– and then secondary languages for any paragraphs or blocks of text that appear in a different language from the primary language. Now, people who use text-to-speech or screen readers, those devices are programmed to read the text using the accents, pronunciation rules, and punctuation of the language that’s designated by the content provider.

Next, provide page titles. You should provide a title that describes the topic or purpose of the content. This is for your web page, any documents, presentations, or spreadsheets. This is not a file name. This is actually provided in a title tag in HTML. Or in other documents, you should go to the file properties and enter the title.

The image on this slide is a web browser. It has three web pages open and red arrows pointing to the title of each web page. One says 3Play Media, the W3C Web Content Accessibility Guidelines, and the third is WebAIM Accessibility. Braille translators, screen readers, and speech synthesizers, they all identify content by title. And this allows people to only open and read the content that’s relative to their needs. Titles are also used to announce which web page or documents are currently open, and titles appear in site maps and search results to aid in navigation.

Next, under readability, semantic structure. Use proper headings structure. And there are headings level H1, or Heading One, through H6, or Heading Six. Use Heading One, or H1, for the title of the document, H2, or Heading Two, for section titles, and H3, or Heading Three, for subsection titles, all the way down to Heading Six. Use true bulleted lists when the order of list items does not matter, and an ordered list when the order of list items does matter.

Also, be sure to use strong, not bold, and emphasis, not italics. Refreshable Braille, screen readers, and text-to-speech, they all summarize content based on this heading structure that you provide and other semantics to convey the layout for those who cannot see the content or understand the text. The example of this slide is a comparison of a document using accessible structure and one that is not accessible because there’s no structure.

The first image is a document with a heading and then adequate whitespace, a section heading, and then paragraph text, followed by a bulleted list, whitespace, another section heading with paragraph text, whitespace, a subsection heading three with whitespace, and then a numbered list. So this document provides proper structure.

In comparison, the second image on the slide has no structure and it simply appears as a full page of run-on text. This is what happens when we don’t use that semantic structure. And you can imagine how difficult it would be to understand web page content or academic course content when there’s no structure provided in the documents. You provide structure in HTML using tags, in Word and Open Office using styles, and in PDF documents using tags.

And the last item today under readability is text spacing. This is specifically for web designers using style sheets. But the information can also be applied to documents. WCAG says that there should be no loss of content or functionality that occurs by setting all of the following. So in essence, you should go into your style sheet and set the letter spacing or the tracking to at least 0.12 times the font size, the line height or line spacing to at least 1.5 times the font size, word spacing to at least 0.16 times the font size, and spacing following your paragraphs to at least two times the font size.

Now, when you go into your own CSS and change these settings, you should then review your web page content and be sure there is no place where text overlaps or where text is cut off in any places. People with dyslexia or who have low vision may apply their own personal style sheets to your web pages using these or similar settings. And this will increase the space between letters, words, lines, and paragraphs to assist in both reading and comprehension of content.

Tip number three, reflow. This is for websites using responsive design. Ensure that the content can be presented magnified at 400% without loss of information or functionality, and without requiring scrolling in two dimensions. So you should not require both horizontal and vertical scrolling.

Now, if you develop PDF documents, it is important to note that PDF accessibility checkers often include an option for reflow. And what this does is temporarily present your content in a single column to ensure readability when the text is magnified or enlarged. So this benefits people with both cognitive and visual disabilities. It will reduce the amount of onscreen text for people with cognitive disabilities who experience cognitive overload, or for people with low vision who enlarge the text to make it easier to read.

The examples on this slide contain three images. The first image is a sample of original text in a document. And this is a document with two columns. The first column contains just four examples, all letters A. And the second column contains all letters B. When you apply reflow, the content should reflow to a single column.

And the second image conveys proper reflow. And this is where the text has been enlarged, and the two columns have now reflowed to a single column. The letters A from the first column appear first, and below or after that, the letters B appear.

The third image is an example of what does not reflow properly. And here, the text has been enlarged, but the document remained in two columns. Due to the large font size, you can only read partial letters A. You cannot see all of the A’s. And none of the letters B are visible.

Tip number four, orientation. And this says that content does not restrict its view and operation to a single display orientation. It should be able to view and operate in both portrait, or vertical, orientation and horizontal, or landscape, orientation. There are a few exceptions. A bank check is always a landscape orientation. A piano keyboard is always landscape. But in general, your content should not restrict view.

This benefits people with cognitive, motor, and visual disabilities. Some people need to fix their page orientation either to ensure that less text appears at one time or to be able to enlarge the font size. Also, some people will affix their tablet device in a single orientation.

The image on this slide is from Displays2go. It’s a table mount arm that is affixed to a wheelchair. And here, the tablet device is fixed in the landscape orientation.

Tip number five, keyboard accessible. All functionality is operated using a keyboard. What you should do is unplug your mouse and, only using your tab keys or your up and down arrows, tab through all your content. Make sure that all of the content can be accessed. If you have forms, that all pages of the forms and all form fields can be accessed using only the keyboard, as well as tabbing through a table of contents or other content in a learning management system for online courses.

So we ensure that there’s keyboard-only access, and also that you don’t experience any keyboard trap. This happens when you tab into a form, but you can’t get to the Submit button. Or you may have a media player on your website that’s not accessible. So a person will tab into the media player, and they can hit the Play button, but the Tab key won’t go to Pause, Stop, or Forward to activate the captions. This benefits people with cognitive, motor, and visual disabilities.

Many assistive technologies rely on keyboard-only or virtual keyboard navigation. We talked earlier about speech-to-text. And screen readers, speech generators, and eye trackers, they all rely on keyboard functionality.

Also, people who have motor disabilities may not be able to use a mouse, or they may have limited hand-eye coordination. And also, people who have low vision may enlarge a web page so large that they can’t see the mouse pointer on the screen. And they also rely on keyboard navigation.

Now, some of the basic requirements for keyboard accessibility are related to our next tip. But if you would like more information on how to ensure or how to test for keyboard accessibility, there will be a link distributed with the resources after today’s session for a document from WebAIM called “Keyboard Accessibility.”

So tip number six is navigation. Help users navigate the page, find specific content, and determine where they are. There are a number of ways to do that.

And four ways that we will discuss today are to bypass blocks of text, ensure consistent navigation and identification, provide descriptive hyperlinks and, with keyboard access, ensure the proper focus order and that the focus is visible. This benefits people with cognitive, motor, and visual disabilities. And in general, it allows for ease of navigation, which benefits everyone.

The first we’ll talk about is navigation. Bypass blocks of text using Skip to Main Content. One of the best examples of keyboard accessibility is the WebAIM.org website. And the image on this screen is the WebAIM home page. When you visit the web page, select the Tab key, and this will activate the Skip to Main Content link.

And then, when you press Enter on your keyboard, it will jump the tab, following the red arrow in this image down to the main content. So in this way, you can skip the nine navigational elements on their home page. Now, Skip To links help to reduce head and neck strain for people who use a mouth stick.

It also helps to reduce audio fatigue for people who use read-aloud technologies like a screen reader. They’ll listen to content read aloud as they navigate web pages. And this way, they’ll only hear the Skip to Main Content link and the main content, but they won’t have to listen to a repeated announcement of all the navigational elements.

The next item under navigation is consistent navigation and identification. Consistent navigation means that mechanisms repeated on multiple pages occur in the same relative order. One example is a navigation menu.

Now, often on multiple pages, the menu items will change. But in general, throughout a website, ensure that your navigation remains in the same relative order. Also, that the Skip to Main Content link is always in the same location, the Search field is also always in the same location. Consistent identification means that components with the same functionality are identified consistently.

And examples are a Submit button. And here, there’s a red Submit button. So if you have forms throughout your web page, and you use submit buttons, if you use a red Submit button, you should always use a red Submit button. Or to go to the next page, if you use a green Next arrow, you should always use a green Next arrow.

Predictability is a key component of accessibility, especially for people with cognitive limitations and memory loss, and also for people who do not rely on sight. They can predict the functionality or layout of multiple web pages based on the first page they visit.

The next item under navigation is descriptive hyperlinks. And this means that the purpose of each link can be determined from the link text alone. And also, remember that the link text should be unique for all unique destinations. So there are two examples on this slide. And for each, there is a pass and fail. So the first example, which is a pass, is a descriptive link text that says W3C Homepage. A fail would be only providing the URL to the W3C site.

So a URL is not descriptive of the location or document that will open when they visit that link. The second example is for a document. And the pass is– descriptive hyperlink text says Captioning Tip Sheet, in parentheses, PDF. And the fail would be standalone text that says, Click Here. As I mentioned earlier, some assistive technologies will aggregate the web page links into a single list, and then read that list out loud and separately, out of context from the main content, to facilitate navigation.

And the last item today under Navigation is focus order and focus visible. Now, focus order means that navigation, using your Tab key, receives focus in an order that makes sense. Focus visible means that, as you tab through, the keyboard focus indicator, which is the location of the Tab key, is always visible.

The example again here is the screenshot of the WebAIM home page. Their navigation menu items have black text with a white background. But as you use the Tab key and tab through, the item on the navigation menu that receives focus will change to red text with a red border. So this makes the content a logical focus. Making your tab focus indicator visible makes the content predictable, and it also ensures that people who navigate sequentially through a web page using tab, instead of randomly using a mouse, will encounter information. They’ll know exactly where the mouse is located.

Tip number seven, enough time. And this is regarding time limits. Provide users enough time to read and use content by providing a mechanism to either turn off the time limit, adjust or customize the time, or extend the time limit. And this benefits all people with disabilities– cognitive, hearing, motor, or visual. Often, people need more time to read, understand, and navigate content.

There are two examples on this slide of how to ensure accessibility with enough time. The first example is a multi-page form. And one way that you could make that accessible is, on the very first page, before a person would encounter a time limit, provide a checkbox that says Allow Additional 15 Minutes Per Page. A second example– this is a pedestal kiosk from Advanced Kiosks. They sell accessible kiosks.

So when you have a kiosk, you need to ensure that the unit itself is accessible. This includes wheelchair access, Braille for the keypad, a headphone plug-in, and other features. Make sure the unit itself is accessible. And then the software that’s running on that unit needs to be programmed with accessibility in mind.

Now typically, for a kiosk, it will time out after a period of inactivity, meaning that a person gets partway through a feature and then just walks away. Now, to make a timeout accessible, you should provide a statement asking if the user is still there or still working, and ask them to hit any key to continue. And then you should program to ensure that there’s 20 seconds before the timeout occurs. And 20 seconds in accessibility is an acceptable wait time for enough time.

Tip number eight, color and contrast. Regarding the use of color, ensure that color is not the sole means of conveying important information, indicating an action, prompting a response, or distinguishing a visual element. In essence, ensure that we don’t use color coding.

Contrast ratio. Ensure there’s a sufficient contrast between your foreground, or your text color, and the background color and between non-text elements, like a form button or a Submit button, and the color surrounding. This benefits people with both cognitive and visual disabilities. Now, for people with cognitive disabilities, color is very important, so we want to ensure that we still use color. But for people with visual disabilities, be sure that the meaning of the color is redundant, meaning to avoid color coding for people who cannot see the color.

Regarding the specific contrast ratio requirements in WCAG, for text, there should be a minimum contrast ratio of 4.5 to 1. For large text, 18 or 14-point bold, a minimum ratio of three-to-one. And for non-text elements, like user interface controls, a minimum contrast ratio of three-to-one.

There are two images on this slide. One is a pass and one is a fail for contrast ratio. The pass is a box with a white background and a blue rectangle. This might be a form element or a navigation item, or even text compared to background. And this will pass. There is sufficient contrast.

The second image is a fail. And this is a red box with a gray circle inside. And there’s not enough contrast between the tone of the grey and the red to ensure accessibility. So these ratios are calculated so that color is not the key factor in differentiating the elements, and it makes the contents more readable. There will be two links provided with the resources for today’s session for two free tools that you can use to determine these contrast ratios.

One is the Color Contrast Analyzer from the Paciello group. It’s a great tool, especially for checking color contrast in PowerPoint presentations or slide shows. And then the other tool is for WebAIM’s color checker. They’re both great tools and they’re both free to use.

Tip number nine, text alternatives. Provide text alternatives for non-text content. It might be an animation, a chart, or a graph. It could be form controls, icons, an organizational chart, photographs or thumbnails, et cetera. Anything that is not text by nature needs to provide a text alternative.

Now, this benefits people with cognitive and visual disabilities. People who have difficulty understanding or seeing visual elements will benefit by accessing the text instead. Also, assistive technologies like screen readers cannot read graphical elements. Instead, they read aloud the text alternatives when they encounter any non-text elements, so we need to provide text alternatives.

The example on this slide is a complex image. This example comes directly from the W3C web accessibility tutorials. W3C is the group that authors the WCAG guidelines and they have a great set of accessibility tutorials. The link to the tutorials will be provided in the resources for today’s session. And this example comes from their images tutorial on complex images.

So there are two images on this slide. The first is a bar chart that uses colors to determine different amounts on the chart. Now, one problem is it’s color-coded, so it’s difficult for people with visual disabilities. However, the color is very important for people with cognitive disabilities.

So one way to address this, if you have a chart, is to do the second image on this slide, which is a data chart. So you can convert the data in a bar chart or a pie chart into a table. And this is a black and white text table that would be accessible for people with visual disabilities.

Now, also for your complex images, you need to provide your text alternative and what’s called a long description. Text alternatives are limited to 120 characters or less. So for a specific example of this complex and other types of images, you can visit the WCAG tutorials from the W3C and go through and learn how to write the alt text, or the text alternative, and the long description.

Number 10, our final tip for today, is, provide accessible alternatives to media. So if you provide audio-only, video-only, audio and video combined, audio and video combined with text– for example, in a tutorial– we need to provide accessible alternatives for that media. Also, we need to always ensure that the media player itself is accessible. You can conduct an internet search for accessible media players. There’s great information available and there are media players that you can use to ensure accessibility.

Accessible alternatives benefit all people with disabilities– cognitive, hearing, motor, and visual. The alternative formats allow the media to be rendered in other ways, through other modalities like hearing, sight, or touch, depending on the person’s need. The multimedia types of accessible alternatives include– and this is an alphabetical list– audio descriptions, captions, descriptive text transcript, media alternative to text, and sign language. So today, we will go through each type of accessible alternative. And then, at the end, we’ll talk about different types of media and when to use each of these alternatives.

So the first alternative is an audio description. This is audio that’s been added to the natural pauses in an existing soundtrack. It provides important visual details that are not described in any dialogue or any other audio in the soundtrack. An extended audio description is when there’s not enough time in those natural pauses to describe any visuals that are taking place. This extends the length of the original soundtrack.

And just a note– if your descriptions of your visual details are provided in the audio narration, or if the video is just a talking head, then audio description is not needed. So if you imagine a movie with action taking place, typically during that action, there’s no audio dialogue. And that’s where these audio descriptions would be inserted to describe what’s visually taking place.

Next is captions. These are text alternatives that are added to synchronized media for both speech and non-speech information that’s conveyed through sound. They include dialogue, meaningful sound effects, like applause or laughter or any background music that is significant, and also speaker identification. Captions are used by people who have difficulty understanding fast-moving content, people with different types of cognitive disabilities, or for people who can’t hear the audio identifiers.

A descriptive text transcript is a text alternative that conveys the audio and/or visual content via text. And this may include the spoken word– so text of the audio narration– text of any key audible sounds that contribute to meaning, like ambient sounds, key visual information needed for comprehension, and, in the case of a tutorial, hyperlinks to interactive components like a survey that needs to be taken.

People who have difficulty perceiving, seeing, or understanding audio and video content combined will benefit from a descriptive text transcript. Also, people who can’t operate media player controls. People can change text also to other formats, like Braille or speech, depending on the needs of the user.

Next is a media alternative to text. This is a media file that presents no more information than exactly what is presented through text. And formats can include audio-only. If you have a text manual on a web page and you receive an accommodation request from someone who perhaps has dyslexia and doesn’t use assistive technology, but needs the content in audio format, you may provide an audio-only alternative.

Video-only. Often, this could be for a sign language interpretation of text. Or audio and video combined. This may be where you have a silent movie and you add audio description as an audio track to that content. Now, there is a note that since this type of media is itself an accessible alternative to the original text, captions are not required.

And last, [INAUDIBLE] worldwide. There are over 300 different types of sign language. On this slide are three [INAUDIBLE] sign language [INAUDIBLE] are the English language.

However, by country, the sign language may differ. So if you do receive a request for sign language, be sure to note exactly which type of sign language the requester needs. People who are deaf or hard of hearing, for some people, sign language is their first language, and then written text is like speaking a second language. So text itself is less easily or quickly understood.

But they’re fluent in sign language, so sign language is much quicker. Especially if they’re viewing moving content, like a video, some people would prefer sign language instead of captions.

So those are the accessible alternatives. Now, when do we use each type of alternative? So we’ll go through all the information on this slide.

I will note first that if you receive an accommodation request, maybe through your accessibility statement, and somebody requests a different version, that you would provide whichever version that person requires. But in general, without a specific request, if you have audio-only content, you should provide the live audio-only captions to meet level A and AA, and sign language if you want to meet level AAA.

For pre-recorded audio-only, you would provide a descriptive text transcript. And this would meet level A and AA requirements. If you have video-only content that’s pre-recorded, you would provide either the descriptive text transcript or a media alternative to meet level A and AA. And the choice is up to the content provider. To meet level AAA in addition, you would provide the media alternative to text.

If you have audio and video content combined, if it’s live, you would provide captions to meet level AA, and sign language to include AAA conformance. If the audio-video content is pre-recorded, you would provide audio descriptions, captions, and descriptive text transcript for level A and AA conformance. In addition, you can provide extended audio description and sign language in order to meet level AAA.

So this is the end of our presentation. In summary, we have gone through 10 tips to create accessible web content using the updated WCAG. One, accessibility statement. Two, readability. Three, reflow. Four, orientation. Five, keyboard accessible. Six, navigation. Seven, enough time. Eight, color and contrast. Nine, text alternatives. And 10, multimedia.

So at this point, this is the end of the presentation, and I will stop sharing and turn this over to Sam for any possible questions.

SAMANTHA SAULD: So the first question is, “in WCAG, what do the level letters stand for?”

JANET SYLVIA: OK. Are we ready?

SAMANTHA SAULD: Hi, Janet. Can you hear me?

JANET SYLVIA: Yes. OK, those are just three levels of conformance. So level A means that if you follow any of the success criteria, at a designated level A, you will meet minimum accessibility requirements based on the WCAG guidelines.

And also, typically level AA means inclusive of both levels A and AA. So if you also follow level AA, then that meets a middle level of conformance. If you follow level AAA, which means levels A, AA, and AAA, you would meet the highest level of conformance possible with the WCAG guidelines, which the guidelines themselves say is nearly impossible for anybody to do. Is there another question?

SAMANTHA SAULD: Yes. The next question is, “is using a tooltip for a URL in a document in which you want the URL listed accessible?”

JANET SYLVIA: If you visit the Microsoft site, there will be a note that says to use tooltips with URLs. Typically, I would not recommend them because not all assistive technologies can access the tooltips. And so personally, I would not recommend using them. Is there another question?

SAMANTHA SAULD: Yes. The next question is, “how often is the WCAG updated?”

JANET SYLVIA: Well, they officially say it’s updated periodically. There is already work to make an update beyond the current, which is 2.1. It depends on the work of the W3C, how assistive technologies are updated– how frequently– how frequently web-based content changes. So they announce when they are working on a new update or when one has been released, or the different stages it goes through before its release. So it’s hard to actually say.

SAMANTHA SAULD: Thanks. The next question is, “I want to redesign our website with accessible functions. Where can I measure if the website has met AA or AAA easily without reading all of WCAG?”

JANET SYLVIA: Yes, WCAG is– I think the documentation is over 400 pages, and that’s extremely difficult. One of the best things to do is to use an accessibility checker. There is one from the University of Illinois in the US called the Functional Accessibility Evaluator, FAE. And it’s a very thorough accessibility check. It’s a free tool.

And so you can sign up on their website. I don’t have it. If we would like to provide it afterwards, please, Sam, let me know. But it’s called FAE and it would be a great way to check. It can crawl through some of the web pages. And so if you have a complicated site, it’s really a great tool to use. There are other tools as well, but often, I try and mention a free tool first. Oh, great. Somebody just put it in the chat.

SAMANTHA SAULD: “I was under the impression that icons did not typically need alternative text if they are purely decorative and don’t convey any necessary information. Is that still true?”

JANET SYLVIA: It depends on the icon and how the icon is used. So for example, if you have an online form and you have required fields, and you want to use red text, for example, to indicate that it’s a required field, one way to make that accessible is to also add an icon before the text that says “required.” The alt text of the icon would say “required field.” So people who cannot see or access the icon would hear the alt text read aloud.

So it depends on how you’re using the icon itself. You’ll notice that, during my presentation, some of the slides had purely decorative images and I did not verbally describe them. So if it is just purely for decoration, typically, you do not need to provide alt text.

It would be great– if you are interested in viewing the W3C web accessibility tutorials on images, they have great examples and information there. And it’s a just short, quick tutorial that you could gain more information if needed.

SAMANTHA SAULD: Thanks, Janet. The next question is, “how does the WCAG decide what things need to be updated?”

JANET SYLVIA: Well, I am not involved with W3C myself. I have observed their processes. And as I mentioned earlier, it typically depends on how technology advances.

So for example, WCAG Version 1 did not include any information about mobile technologies because, at the time, mobile technologies were not prevalent. But then, suddenly, mobile technologies are everywhere, and they needed to update WCAG.

So it depends on that. And it also depends on assistive technologies and, I guess, the timeline on how they are updated. Because sometimes, they may be updated to the point where certain accessibility requirements may not be needed.

But it’s across the span of 20,000 different types of assistive technologies, but they have different patterns. And actually, if you were very interested in this, if you visit the W3C website, they have documentation that explains how they update WCAG. So if you were curious, you could find that information there. It’s a short bit of information but it’s very informative.

SAMANTHA SAULD: Great. The next question is, “you spoke about tables being better for data. However, what are your thoughts on using tables to organize information? Is this OK, or is it hard for various readers?”

JANET SYLVIA: Tables should not be used for layout. Instead, they should be used specifically for data. So I think that answers the question.

SAMANTHA SAULD: Great. Thanks. The next question is “also, is there a generator for sign language translation that you would recommend?”

JANET SYLVIA: Well, at this time, I’m not familiar with one. But I do know that there’s research underway that would have a translator to translate text to sign language. Right now, I’m not familiar of one that is ready for use, but I do know it’s something that’s under research that would be really beneficial for lots of people.

When I mentioned that there’s currently over 300 different types of sign language, there’s a lot of conversion that would need to take place. But there are groups that are working on that, so that’s a terrific question.

SAMANTHA SAULD: Thanks. The next question is, “if a hyperlink is listed as plain text, does it need alt text?”

JANET SYLVIA: So a hyperlink is typically text. Sometimes, it can be an image of text. But if the hyperlink is just text, it might just say “W3C home page” for the hyperlink.

So I’m not sure. You don’t need alt text for text. But if your hyperlink was an image– for example, if you had a logo or another image that was a hyperlink to something– the alt text for that image link would be the name or the title of the web page or the destination document that would be opened when you visit that link. I hope that answers.

SAMANTHA SAULD: Thanks. And for our last question, someone is asking, “do you have examples or links of a pre-recorded video with audio meeting AA?”

JANET SYLVIA: Let’s see. I’m not sure if I understand that correctly. Are they looking for examples of audio descriptions? They are AA. And if so, the American Council for the Blind has an audio description project website. And they have great examples of audio-video where they have inserted audio descriptions. I’m not sure if that answers the question.

SAMANTHA SAULD: OK, thank you.

JANET SYLVIA: OK, great.

SAMANTHA SAULD: Thanks, everyone, for joining.