 Good afternoon, everybody. My name is Gay B. DeYoung, and I'm a member of the IT accessibility team, and today I will present on best practices for accessible electronic documents. And this is our agenda for the afternoon. We'll start off by, excuse me, reviewing the principles of accessibility and how they relate to success criteria for creating accessible electronic documents. And then I'll go over best practices for making Word documents and PowerPoint slide decks accessible for individuals who use screen readers or other assistive technology users. And I'll also examine what is required for accessibility of PDF documents and I'll briefly touch on InDesign and the Google workspace and provide some awareness for making content accessible in those applications. And then finally, we'll review when it's appropriate to use certain formats over others. So I wanted to review the four principles of accessibility and we've covered these principles in previous webinars before, but I wanted to review them once again as these principles guide the success criteria that conform to specific accessibility standards for web content. And these standards also apply to electronic documents as well. A key objective of these guidelines is to ensure that content is directly accessible to as many folks as possible, and that it's also capable of being repurposed in different forms to match different people's sensory, physical and cognitive abilities. The first principle is perceivable. Is the information presented to users in a way that they can perceive? Are there text alternatives included for visual content? For folks who cannot hear audio or captions available? Or for individuals who cannot see the video or hear the audio? Is a transcript available? Is content presented in different ways for different user needs? The second principle is operable. Can the user easily navigate around the document and can they find content? Is it clear to them where they are within a document? Is functionality available from a keyboard? And be aware that content doesn't cause seizures for folks with photosensitivity. The third principle is understandable. Is the text readable? And does it make sense? Does the user understand how to use the interface in which they are viewing the material? And does it behave in predictable ways? Our use is prompted to avoid incorrect mistakes. And then finally, the last principle is robust. Is the content robust enough that it can be interpreted reliably by a wide variety of current and future tools? All right. Accessible documents. Many accessibility standards relate to content styling and layout. And for document accessibility, logical structure helps to paint a more clear picture in the user's mind. And this is achieved by using navigation elements such as a table of contents, heading levels, and lists. Descriptive body copy is often overlooked, but it plays a significant role in accessibility. Content should describe supporting materials such as charts and graphs, and that sets the framework for those graphics. Descriptive body copy can also help keep alt text short and to the point. You want to make sure to include color friendly palettes that have a high contrast ratio between the foreground and the background to make it easily distinguishable for those who may have low vision. And also be sure to include text for visual elements such as images, graphics, and charts. The relationship between headings, paragraphs, figures, and page structure allows the reader multiple ways to navigate the document reliably. Establishing predictable patterns in documents helps the reader gain familiarity with the content as they cycle through those pages. And now that we've established an understanding of the basic principles and requirements for accessible documents, I wanted to take a little bit closer, deeper look at the software applications and the tools within those applications that can help guide a content creator to making more accessible document. I do include images of screenshots for many of the upcoming slides and these were taken from Office 365 and Windows, unless otherwise noted. I'm presenting on a Mac and later on if we have some time I might demonstrate something in Office or Adobe Acrobat, but I'll mention if the steps for performing the task are any different in the Windows environment. So let's take a deeper look at each one of these, each one of these settings here. Headings and styles provide navigation. When reading a document, side of viewers can scan a page and use visual cues like larger or bolder text to help find a section of a document that they want to read. However, for somebody who uses a screen reader, those kinds of visual markups aren't very useful. Using styles and headings allow a screen reader user to navigate from section to section heading to heading rather than having to listen to the entire content of a document from the top of the page to the bottom. It's important to use the styles pane and choose the most accurate style to create the scaffolding that will form an outline of the content rather than manually marking the text is bigger and bolder. Using the pre-formatted text in the styles pane as that provides an anchor point for screen readers to navigate by. So you can kind of think of a style as a set of predefined formatting instructions, and that's utilized consistently throughout the document, and it's kind of used to tag or identify parts of the document. The styles can be easily modified in the styles pane by selecting the dropdown menu, and that change will be applied to a particular style throughout the document. And on this slide, I've included an image of the styles pane in Word for Windows. The styles pane in both Windows and Mac is found on the home ribbon and can be expanded to view all of the styles that are included in a document. When using styles, this provides an outline that can automatically be used when initiating the table of contents tool in the references tab of Word. So for longer documents of 10 pages or more, using styles in combination with the table of contents provides additional navigation aids that actually benefit all users. Alt text for images. So alt text, as we know, provides textual information for visual and elements contained in a document. And it should provide a brief description of the image and why that image is relevant. I've included an image of the alt text panel in Word where content creators can add or change the alt text to images, graphs, and charts. To expose the alt text panel in Word, select your image and then notice that the picture format tab becomes visible. On that tab will be an icon that says alt text, and then selecting that will make the alt text pane pop out on the right hand side. Now in the center of the pane, a text field is available to include a description of the alt text that you want to include. And above that sits some information about how you can construct your alt text and it says how would you describe the object and its context to someone who is blind or low vision. And then it gives some additional hints such as the subjects and detail, the setting, the actions or intentions, or any other relevant information. It's important to note that when you add an image to a Word document, alt text will be generated automatically using Microsoft's AI for creating alt text. Now this can be turned off in the ease of access panel on Windows or in the preferences panel on Mac, but you should review the automated text to determine if it accurately describes the image, or if it provides vague or inaccurate information and then make any corrections as necessary. And you'll also notice that there's a button on this panel that says generate a description for me. Selecting that option will provide automated alt text as well that again uses AI. And I invite you to try this, but keep in mind it does have some limitations, so you may need to need to help it out there with some some accurate text. And any images that are decorative should be marked as such as they can be kind of redundant and often annoying for screen reader users. So in office all you would need to do is just check this checkbox right there and that will signify to the screen reader to ignore it. Formatting lists. I mentioned lists earlier as they are another way of creating structure and content and documents rather. And you want to make sure to use the correct list generating tool to do that. Use the bulleted list tool to create unordered lists and the numbered list tool to create ordered list. And the image on this slide shows the multi level list menu that helps with creating nested lists or what are known as description lists and HTML. It's a little tricky to use but it's much more effective than using the regular bullet list tool and indenting nested lists manually. The multi level tool will do that for you and keep track of the levels which will ensure that assistive technology will announce the lists and sub lists accurately. Formatting tables. For tables by default, assistive technology and screen readers will read a table from left to right, starting at the top. If the relationship between the cells is not clearly defined, then the table is not formatted accurately. If heading cells aren't associated with corresponding data cells, a user can quickly get lost in a sea of data. So if you're including a table in your document, be sure to review the table properties and assign a header row within your table as this helps screen readers and assistive technology announce the table data in a more meaningful way. Simple tables and office applications can be made accessible, but complex tables that are nested or have merged cells or split cells cannot. The image on this slide shows the table properties dialog box, which allows the content creator to assign the top row of a table as a header row. Now to get to this point, the content creator can select the top row of a table. And this will make the table design tab and layout tab visible. Select properties from the menu and this will launch the table properties dialog box that we see here on this slide. So from this dialog box, select the row tab, and then select the checkbox that says repeat as a header row at the top of each page. So you want to make sure that that's checked. And this will define the top row of the table as a header row and will help screen readers and other assistive technology announce the data in that meaningful way that will associate those headers with the data to increase the accessibility of the table content creators can also design a summary of the table by selecting the alt text tab on the table properties dialog box. And then you conclude just a brief summary about how the table is constructed, which will may help the screen reader users navigate that table. If you have complex tables that are nested, you may want to consider simplifying them as this will make it easier for everyone to understand the relationship of the data presented within those tables. Meaningful hyperlinks. Meaningful hyperlinks and electronic documents make it easier for screen reader users to determine what that link is all about. Other than listing a URL which can have a long string of letters and characters using meaningful hyperlinks helps users to know something more about the destination of the link if they decide they want to click on it. Try to avoid using text that says vague things such as click here. And the image on this slide shows the insert hyperlink dialogue box. To create a meaningful hyperlink. First, the content creator will need to select the text that helps identify where that link will go. Then they can select the insert tab from the home ribbon from the insert tab. Select link from the menu and insert and the insert hyperlink dialogue window will appear just like we see here on the slide. Right down here is where you can add the URL to this field and that will turn the selected text into a meaningful hyperlink. And what that will do is when a screen reader user what they can do is they can call up a list of the links. And that meaningful text will be included in the list and give an indication of where that link will take you. The content creator uses click here or link as their descriptive text. And what happens is a screen reader user calls up that list of links and then they will encounter the screen reader announcing click here click here click here or link link link. Which doesn't really give the user clear information about where that link is going to take them. So creating meaningful hyperlinks and electronic documents is absolutely essential for accessibility. Adding document properties allows screen reader users to get a bit more information about the document without the need to actually open it. And for someone who uses a screen reader or other assistive technology this can help limit the need to open a document to determine if it's actually the one that they're looking for. So adding a document title a summary and keywords are also helpful for searching and indexing of electronic documents. And the image on this slide shows the properties dialogue window where a content creator can include additional information about a document including title author and keywords. Now to get here in Word for Windows from the file menu select info and this will present the content creator with many options to view or change document properties. But from there select properties then advanced properties to launch the dialogue window we see here. On the summary tab you want to on the time you tap is where you want to add your document title and this is where you can add author and keywords as well. So on the Mac the steps to find the document properties are the same so you go to the file menu and select properties then go to summaries tab to make any adjustments. Document language. We are increasingly working in a world where we have many different languages that we encounter in our electronic electronic documents. And it's important to include the accurate language attribution to either the entire document or to specify a block of text in another language. And as many screen reader applications do support multiple languages and can switch on the fly if they have the correct language dictionary install between those four ported languages. So for most of us the default language setting for creating documents and offices English. The image on this slide shows the language dialogue window and to assign or change the language of text within a document. The reader would select the text then select the review tab from the home ribbon, and from the review tab select language drop down. Now from this drop down there are two different options there's the option for set proofing language or language preferences set proofing language allows the content to creator to change or mark the selected language as a different language than the default language as shown here in this image on the slide. Language preferences will allow you to set the language preferences for office and this will change the language of all your office applications so your buttons, your menu and other controls can be managed there. That window also allows you to upload and add additional languages for authoring and proofing. Now that you've taken all this time to create a more accessible word document using headings lists styles, adding alt text for images formatting your table header and adding metadata. It's important to know the proper steps for exporting or saving your word document as an accessible PDF to maintain the proper accessibility formatting. There are several ways content creators can save or export a word document in PDF, but only one way maintain accessibility PDF maker is broken. Some of you may remember back in September, Adobe issued an update to PDF maker that caused quite a stir among content creators who create accessible content and remediate inaccessible content. PDF maker is kind of built into our enterprise last license of office and the update created some serious issues such as alt text, not converting from word to PDF cell borders and other markings for tables and other graphics and underlines for hyperlinks would be tagged as paths instead of being artifacted and a bunch of other issues as well. Now, Adobe has since fixed those errors, but PDF maker is still broken and never really worked very well to begin with. So if you see an acrobat tab in either word or PowerPoint, do not use that as an option to convert your document to a PDF as it will not create an accessible PDF. The mapping of content and word to tags and PDF isn't accurate and using this method will result in inaccurate semantic tags. Instead, use the save as feature from Microsoft file menu. Now on the slot I have two separate images. The first image shows how to save a word document as PDF in the windows environment. The proper method is to go to the file menu and select save as from the options, then choose PDF as your export format. Then selecting the more options link will open the options dialogue window that we see here on this on the slide. To confirm that the checkbox for the item document structured tags for accessibility is selected and then continue to follow the prompts to save your word document as an accessible PDF. On that creating an accessible PDF from word are slightly different. The second image on this slide shows a couple of different options when selecting PDF as the output file format for Mac. From here the content creator will be prompted to select the best option for exports, either best for electronic distribution and accessibility, or best for printing. And of course we want to select best for electronic distribution and accessibility as that maintains the features that were used that were created within the original word document, and will produce a tag PDF that is accessible to screen reader users, and have done accurately know for the remediation is needed for that PDF. Now later on in this presentation I'll talk more about accessible PDF and what a tagged PDF means. Essentially a tagged PDF with good semantic structure is usually an accessible PDF. But for now let's go ahead and switch our attention to accessible PowerPoint. So all the steps presented in the previous slides that make word documents accessible also apply to PowerPoint, but there might be a few modifications. PowerPoint also functions differently than other formats as the content distributed throughout the slideshow is often very visual and image based. One thing that makes PowerPoint a bit more complicated is that people can consume the content in various ways. They might be watching someone present the PowerPoint such as you are now, or they might be viewing a PowerPoint on their own computer, or they may be viewing printed slides. The way in which somebody interacts with the slideshow is going to shape if and how they can access the content. When presenting, even if you don't intend to distribute your PowerPoint, it's always important to remember that for somebody who can't see your presentation, you must explain all the content presented on each slide. So let's take a look at each one of these points in greater detail. Using built in slide templates. An important part of making accessible slide decks is to use the layout templates built into PowerPoint. And this is important because screen readers may jump over or ignore items like text boxes that are added to slides that exist outside of the content boxes provided. You want to avoid selecting a blank slide and then adding text boxes to populate with your slide. Instead, select a layout template from the new slide drop down menu on the home button as shown in this image on the slide. PowerPoint doesn't really use headings instead the slide title in the layout templates essentially function like headings and that they aid and navigation and provide structure for the content. Every slide in a presentation must have a slide title and each slide title should be unique. Duplicated slide titles can be confusing and make it difficult for someone to find information and they're looking for. So for spillover information use numbering in the slide title such as one of two and two of two. Also individuals with dyslexia describe seeing text that swim together on a page. They often see text merge or distort so for people who have dyslexia or low vision, consider reducing the reading load of the text on the slide and use a larger font of about 18 points or more. It may also benefit from using familiar sans serif on such as Ariel or Calibri. And you should avoid using all caps and excessive use of italics or underlines, as that can be kind of visually distracting and make sure that you have ample space between sentences and paragraphs to help out with clarity and readability. Okay, reading order of slide contents things are going to get a little complicated here. So reading order of slide contents when it comes to screen readers announcing information is usually presented in the order it was added to the slide. And this makes it critically important to check the reading order of your slides as content creators often add elements to slides when editing. The message on this slide shows the reading order pain in PowerPoint from Windows to get to the reading order pranks to get to the reading order pain, select the review tab from the home ribbon, then select the check accessibility drop down. Here content creators have four options to choose from they can either check accessibility, which does just that and we'll go over a little bit later on in this presentation about accessibility checkers so I'll come back to that in a second. Then you can also choose alt text, and this is another way to expose the alt text pain. And there's an option for the reading order pain, and then there's an option for options accessibility, which exposes the accessibility settings in the PowerPoint options dialogue. Right now what we're looking at is an image of the reading order pain in Windows, which shows us the elements on a particular slide. So contents on a slide are arranged and read by screen readers in order from top to bottom as one would expect. Now it's possible to move these elements by either dragging and dropping or using the up and down keys here up in the corner, and you can move the content up and down. Now moving these elements will affect the order in which they are announced by screen readers. In this case the slide title should be the first element announced then followed by text content, then the alt text assigned to the group image. You'll also notice these checkboxes that appear just to the left of these elements. Unchecking those checkboxes will signal the screen reader to skip announcing that content, but that content will still be visual on the slide. All right, now selection pain on a Mac. So on a Mac, checking the reading order of a slide is completely different rather. The image on this slide shows the selection pain in PowerPoint for Mac. Now to expose this pain from the home ribbon select the arrange oops, hold on. There we go. Okay. Hold on. There we go. Selection day. Okay, so to expose this pain pain from the home ribbon select the arrange drop down and then select the selection pain at the bottom of that list. Now you might notice something a little bit off when looking at this image and the order in which things are laid out. The slide titles on the bottom and a text place order holder sits just above that title and a picture sits just above the text placeholder. Essentially, the reading order in the selection pain is is instead going from top to bottom. It goes in reverse from bottom to top. Now in PowerPoint for Windows, there is also an option to launch the selection pain from the format tab. The reading order isn't is reversed as well, but using the reading order pain in PowerPoint for Windows makes more logical sense when looking at the actual reading order from top to bottom. The reading order pain in PowerPoint for Windows is a fairly new development and previously users in Windows had to use the selection pain and make sure that the reading order was in reverse from bottom to top, just like Mac users have to do. This is that Microsoft will soon issue an update to PowerPoint for Mac in which they introduce a reading order pain that lists the slide elements in the appropriate reading order from top to bottom. Another difference between the reading order pain and the selection pain is that the reading order pain has checkboxes that can be used to turn off the announcement of text to be read by a screen reader. Whereas in the selection pain, there are these little eye icons, and if you select those eye icons, which are toggle switch, the text will not be visible on the slide, but it will still be announced by the screen reader. Okay, grouping images. Now I mentioned alt text for images and word, and the same is true in PowerPoint. To add alt text to an image, simply click on the image or select the image and from the picture format tab, select alt text and that will pop out the alt text pain. But if you have multiple images on a slide, you might want to consider grouping them, grouping similar images by going to the arrange dropdown menu on the home ribbon. And the image on this slide shows how to group images in PowerPoint for Windows. First, you'll need to select all the images you want to group together. And then you want to select the arrange dropdown from the home ribbon, and then select group images. Effectively what this does is it flattens the image into a single unit, and then you can apply alt text to the entire group, rather than each individual image, and this may save you some time. Okay, export PowerPoint to create PDF. So if you plan on saving your PowerPoint slide deck as an accessible PDF, the steps are similar to the steps for saving an accessible Word document in Windows with a few modifications. Just like in Word from Windows, go to the file menu, but instead of using save as, choose export from the list of items. And from here you'll have options to export to various types of multimedia, but you'll want to choose create PDF slash XPS document from the export list, as that will maintain the accessibility of your slide deck. Then follow the prompts and double check the options to include document tags for accessibility, and then select publish from there. Now PowerPoint to PDF from Mac. Unfortunately, saving an accessible PDF from PowerPoint from the Mac is not really possible at this time. This is a screenshot from Microsoft's website that gives instructions for saving their office documents to accessible PDFs from various formats. And toward the bottom there, you can see what they're calling a tip. And this is specifically for PowerPoint or Mac. And it reads PowerPoint from Mac OS does not provide this option with saving as a PDF, but you can save your presentation to OneDrive, open it in PowerPoint for the web and download as PDF from there. PDF files generated from PowerPoint from the web present tagging. Now I tried this to see what kind of a PDF document I would get, and it did produce tags, but the semantics of some of the tags were incorrect. Specifically, the slide titles were tagged as paragraph, rather than heading. So this method isn't 100% accurate either. But for the time being, this seems to be the more most accurate way for creating an accessible PDF from PowerPoint in Mac until Microsoft addresses this issue, or Adobe addresses this issue. Common barriers to accessible content, rather. I wanted to bring up some common barriers to accessible content that I still see happening on occasion. Microsoft Office products have been around for quite some time, several decades, and some folks have developed some workarounds for laying out content rather than using the formatting tools built into the application. And sometimes these workarounds actually cause barriers to accessible content in electronic documents. So I wanted to point out a few common barriers that I still see used on occasion that really should be avoided. And offer some possible solutions. So first on the list are text boxes. Content creators sometimes use text boxes as a call out to emphasize the thought or to provide a quote somewhere in the margins or something like that. And it's important to understand that screen readers read and navigate information in electronic documents in line in a linear fashion. So if a text box is inserted into a document, let's say in the margins, a screen reader may miss that information, or if a screen reader does catch it and announce it, it may be out of the normal reading order, which can cause confusion. And in that case, the solution is just not to use text boxes. Now I still see some document creators using tabs and spaces to format text in order to make it look like columns. And this causes some very unpredictable results when using a screen reader or other assistive technologies. So to make your text flow accurately, use the column layout tool on the home ribbon in order to flow the text as a column, or three or four columns. Non printing characters, such as hard carriage returns, multiple spaces or multiple tabs, especially if there are many of them in succession to move text to a certain area on a page will also be announced by the screen reader and this can be very annoying. So instead of using hard carriage returns to create space between paragraphs, you can actually use the paragraph spacing option to achieve the desired look or to adjust the space you want between paragraphs without having those hard carriage returns. You also want to avoid using multiple hard carriage returns to push information so that it ends up at the beginning at the top of the page. You want to use a page break for that instead. Okay, PDF. I want to focus our attention now on PDF at least for the next few slides. And as a review, there are three types of PDF documents. The first type is an image PDF and those are usually created when an article from a book is scanned on a flatbed scanner and the output selected is a PDF file. And this type of document is completely inaccessible to screen readers as the PDF is effectively an image without any underlying text. Now on this slide, I have a couple of examples of scan documents. The one on the left is a scan that is kind of hard to read the text fades in and out and there are all kinds of markup all over this document underlining and marks that go through the text on the page. Now it is possible to convert an image PDF to text using optical character recognition or OCR. But with all of the markup on this page, it will cause errors when converting that text. Essentially, the OCR engine looks at elements of light and dark and then tries to say meaning. So it sees any of those extra markings there it's going to assign meaning to that. The scan on the right is much cleaner and it's easier to see visually it's a lot easier to read. And when run through an OCR application will yield much better results when converting to text. The second type of PDF document is one that has text, but no underlying structure. Now remember structure is what allows screen reader users to navigate and jump from section to section heading to heading. Without structure users are forced to listen to the content of a document from the top of the page to the bottom of the page, without the ability to navigate exactly where they want to go in a document. The third type of PDF document is one that is tagged and is well structured with appropriate heading levels, lists and other elements that allows screen reader users to search a document and consume the information in a more predictable way. Accessible PDF. All right, I mentioned before that PDF tags are necessary when it comes to accessible PDF. So essentially tags are XML based coding inside of the PDF document that provides structure and necessary semantic information for screen readers to navigate and announce a document. If a document is not tagged acrobat will infer a structure based on the reading order preference setting which can result in page items read in the wrong order or not at all. Now on this slide and I've included an image of a PDF tag tree with document enclosed in brackets at the top of the tree, and that functions as the root tag. And the rest of the tag elements appearing in linear order from the top of the tag tree to the bottom. This is the order in which a screen reader will announce the information and contain within those tags is text content. In most cases screen readers will announce the semantic structure first and then the text content to give more context to the user PDF does support complex tables. And what I mean by complex tables or tables that have other tables nested inside them, tables that have multiple heteros and columns and tables with multiple merged or split cells. Now as it is with HTML tables it is possible to make PDF tables more clear by giving each header and ID so you can specify which headers go with each data cell. So tables created in word or PowerPoint won't generate export IDs when converted to PDF so any complex tables need to be remediated using a dog acrobat pro to add those header IDs. Learning how to use acrobat pro for PDF remediation requires quite a bit of training as messing around in the tag tree can result in unpredictable results. But before you try to make a complex table accessible in acrobat pro. See if the table can be simplified in the native application first. For example, if the table has a series of sections, would it reduce confusion to but divided into a series of tables one free section. Now compared to HTML PDF forms have inherent accessibility limitations. The process for creating an accessible PDF form is incredibly daunting for the content creator in equally daunting for screen reader users to consume. And most PDF form start out as Microsoft Word files or other electronic documents with empty spaces to add the form builds actual form fields must be added and then tag within acrobat pro before the file can be filled out electronically. And when it comes to screen reader user navigation, you when it comes to screen reader user, those they navigate from form field to form field, and its contents must be described to the to the users. So each form control in the PDF needs to be explained using tool tabs and reading order is absolutely critical to make sure the information is understandable and accurate. Once those form controls have been added to the PDF with the proper tooltipper information, they then need to be tagged so that the screen reader will encounter them, and then announce them. And when a screen reader enters a form control it usually switches to a different reading mode, often called forms mode. And while in forms mode the screen reader skips over content that is not a form element or link. And for this reason, it's best to place important information or instructions that apply to the whole form before the force, the first form field is presented. And at this time, math formulas are not supported in PDF. For the sake of time I'm going to skip this slide because it's kind of review of what we've already talked about in previous slides for word and PowerPoint. So when to use PDF. It's important to note that PDF is very well supported in the windows environment when it comes to navigation. But Mac users have a very different experience when trying to navigate a time PDF document, especially when it comes to longer documents. Essentially PDF navigation is not supported well in the Mac OS environment text to speeches but navigation is not. If it's not possible. We recommend that you use HTML instead of PDF and so that format is far more accessible for both windows and Mac users. However, online documents and PDF are still a huge part of digital communication across many industries and institutions. And some users like to download and print documents instead of reading information online. And there are a few cases when folks might choose to use PDF over other formats including publishing secure documents that cannot be altered or copied. Although Adobe Acrobat Pro does allow a content creator to edit a PDF. And there are other free PDF editors floating around out there that can do the same thing. And this still seems to be a popular misconception about PDF. What PDF does do is it preserves the layout of a document for printing including images and typeface, and that seems to be the predominant reason for using PDF. Now back in June of this year Dan Comden, Terrell Thompson and I presented a webinar on alternatives to PDF, and invite you to go back and check that check out that webinar as we talk about the costs of remediating PDF documents for accessibility. We also explored tools that convert PDF to HTML, and you can find a link to that presentation on the Accessible Technology Services website under events and collaboration. WCAG and PDF UA. Now early in this presentation I reviewed the four principles accessibility and I want to explain how those relate to WCAG or web content accessibility guidelines and PDF UA. And what this has to do with document accessibility. Well, the World Wide Web Consortium or the W3C is responsible for website governance and they created WCAG and PDFs are actually officially recognized as web content under WCAG. PDF UA is an additional set of standards that focuses exclusively on creating more accessible PDFs and is based off of WCAG. PDF UA is an international organization standard and that helps determine how to implement WCAG success criteria in PDFs. And these guidelines can help you apply WCAG standards for creating accessible PDF. Conforming requirements for WCAG and PDF UA include that the content of a PDF document must be tagged in a logical reading order. The content must correctly represent document semantic structure. Meaningful graphics must include alternative text description. Security settings must allow assistive technology access to the content and fonts must be embedded. Excuse me. PDF UA is the first complete definition of a set of requirements for universally accessible PDF documents. And it's a more stringent standard than what the built-in accessibility checkers for Office and Acrobat Report and requires additional work to ensure compliance. PDF UA validation just like validation for other standards is broken into two categories. Programmatic, meaning validation run by a software, and then human testing. The human end of the equation requires a human being like you're me to review the document and then potentially test the document using assistive software. Now I personally use the second method to ensure that a document is structured correctly or to test questionable areas. I don't use a screen reader to read the entire document. The only way to tell if a PDF document is truly PDF UA compliant is to run an accessibility report with a third-party application called PAC 2021. Previously this was known as PAC 3 and it's been updated this year. Now this is freely available to anyone to download and use, and this will provide a very detailed report about the accessibility of the PDF document, unless any errors and encounters. But it doesn't give the content creator the ability to correct those errors, such as Adobe Acrobat Pro, which also has a built-in accessibility checker, but does allow you to fix some errors that it may encounter. PAC 2021 checker, as well as most other PDF UA checkers out there, is Windows only. And I've included a link to the accessibility checker on the resources slide at the end of this deck. The human element of this equation to a degree relies on experience. An experienced PDF remediator can look at the tag tree structure and identify areas that may pass the checker, but are still not tagged correctly. Forms. I'm going to skip this slide in the interest of time, as I mentioned, forms before. And I want to talk a little bit about Adobe InDesign, which is a very popular page layout program that uses text and images to create fancy brochures and such. Now it is possible to create a document in InDesign and have it export to a completely accessible PDF document that does not require any additional remediation using Adobe Acrobat or another remediation source. But there is a very specific workflow that needs to be followed when creating InDesign documents for accessibility. And this includes mapping styles to tags using the paragraph style pane and editing the tags in the export tagging menu to ensure proper reading order of the articles. Additional training on learning the workflow for creating accessible InDesign documents is recommended and available through reliable vendors. Now here I've shared a resource, pubcom.com, that provides comprehensive training on how to create accessible InDesign documents that export to accessible PDF. So this is kind of a personal plea for any InDesign content creators in the audience. If you are interested or potentially interested in accessibility training from this vendor, please reach out to me. I'd like to see if we have enough folks who are interested in this and maybe I can arrange to get a group training for UW. So email me and I'll have my contact information at the end of this presentation. Google Workspace. So I wanted to touch base on Google Workspace as many of you are probably using that with other folks for collaboration. Google Docs is an online word processor that lets you create and format text documents and collaborate with people in real time, which is great. Now Google uses a rich text editor to create this content and it should be used with caution as the source material created in the Google Workspace cannot be made as accessible as source material produced through Office 365. Since the Google Workspace can be used at a collaborative basis, the importance of making those documents as accessible as possible is necessary. The best practices for creating accessible Google Docs and slides includes using built-in slides, styles rather, and slide templates to provide semantic structure to those, to those documents. So similar to the tools that Word and PowerPoint have. You also want to make sure to include alt text for images and for images that are purely decorative, those should include empty quotes for the alt text to denote that that is decorative. When creating lists, again, use the bulleted or numbered list feature instead of manually inserting asterisks, numbers, or tabs. And something to keep in mind is that tables cannot be made accessible rather in the Google Workspace as it's not possible to designate header rows or header columns. It's important to note that when exporting a Google Workspace document to either Word or PowerPoint, accessible elements may not map accurately and may not produce an accessible Word or PowerPoint document, especially if you have included tables. And it's not possible to export accessible PDF with tags from any Google Workspace app. Also, Google does not have a built-in accessibility checker to assist document creators with addressing inaccessible content. Now there is a third-party plugin called Grackle that checks for accessibility in the Google Workspace. However, UWIT did do a review of their code and revealed serious security shortcomings and as a result has disabled its functionality from our instance. Document accessibility checkers, okay. Document accessibility checkers are automated tools that help with validating the technical accessibility of an office or PDF document. And in some cases they can help you address any issues that appear in an accessibility report. Now some of the elements that accessibility checkers review include checking for the presence of headings and if those headings are appropriately nested to form an outline. In PowerPoint, we'll check to make sure that each slide has a slide title and each slide title is unique. Accessibility checkers can also check to see if alt text is assigned to visual elements. They can't check to see the substance of the alt text and tell if the textual information accurately explains the image. And let's see here. Checkers will also review any tables that are included in a document and check to see if the tables have appropriate headers and proper IDs associated with those headers. Checkers also check lists are created accurately and do check to see that document properties are included such as document title and a language attribute. And it also makes sure to see that the document doesn't have any restricted access to content as that can limit access to screen readers. And then also accessibility checkers check to make sure that the reading order of a document matches the tab order, but can't tell if the reading order is logical or not. So as you can tell, accessibility checkers do have a significant gap as they're more focused on code and strict technical compliance, not necessarily on usability, design and content. And they truly can't identify how real users understand and interact with documents. So as with any web page documents must be assessed for functional accessibility by manually reviewing a document by using a screen reader. Okay, almost done. Review. Let's see. Some formats are better than others. So before we conclude, I wanted to review a few different file types that we covered and when it may make sense to use one format over another. I mentioned earlier that HTML pages are far more accessible than PDF tables, forms and map and stem content are all fully accessible when presented in HTML. Word has some accessibility with stylistic features such as headings and lists and can present math excessively, but it has limitation when it comes to tables and forms. PDF also has some accessibility with stylistic features and can make complex tables accessible, but forms are awkward and math and stem content are currently not supported, and navigation and PDF as well supported in Windows, but not Mac users. It is four o'clock and we've come to the end of my presentation and I've included some resources here that include creating accessible Word documents and PowerPoint documents. I've included creating accessible PDF from Adobe InDesign, and I've also included the PAC 2021 accessibility checker there. And if you have any questions that you would like to write to me about, you can write to my email there, abd at uw.edu. It's also in the chat if folks just want to copy it. Awesome. So, I know we are right at time but I am willing to stick around if anybody has any questions about document accessibility. So, just to let everybody know I put a link to the webinar archives in the chat, the video for this, the recording for this webinar and the presentation will be on that archives page as soon as we get the video back from captioning. So, if you have any questions feel free to unmute yourself. Oh, sorry, you could go ahead and take the questions in the chat if you want to. We are good there we do have time for maybe one question. Go ahead. Go ahead. I'll go ahead. I mentioned that tables when you merge cells they become inaccessible and sometimes, you know, from a visual point of view merging cells is the thing that I want to do. So do you have any advice about how to deal with tables and alternatives to merging cells. Simplify the table, if you have to merge your cells then it makes it more complex. So simplify the table where you don't need to merge those cells and then it makes a little bit easier. Or if you're going to you if you can't do that then choose a different format to to present your material perhaps an HTML. It's just kind of a limitation of word. So either your option would be to simplify your table or use a different format. Okay, well we are a little bit over time. And I want to be respect everyone's time here. So we really thank you for joining us today. And do make, make sure you get Gabie's email address. And get UW.edu. We have a lot of thank yous for you Gabie. Okay, great presentation. As always I pick up some great gems for you. So we are a little over time. So I'm going to have to cut it off here so I apologize for that everyone. Thank you for the rest of your day.