Week 15: Editing and Publishing Documents

Learning objectives

By the end of this week, you will be able to:

Explain why a document that reads perfectly in an AI chat window can still become inaccessible once it is exported to a file.
Describe the difference between a properly tagged document and a document that is only "visually formatted."
Use a durable, general method, not a memorized menu path, to look for a built-in accessibility checker in a mainstream word processor.
Explain what a tagged PDF is, and why a "print to PDF" step can sometimes produce an untagged, inaccessible PDF.
Describe how to ask an AI tool to help verify or regenerate a properly tagged PDF.
Produce clean, accessible HTML output, using heading tags, list tags, and table headers, as an alternative to Word or PDF.
Apply a five-point accessibility review checklist to any document before sending it, in any of the three formats.
Finish a professional document you have already drafted, turning it into a properly formatted, checked, and fixed accessible file.

Lesson

From a good draft to a file you can send

Earlier lessons in this course walked you through drafting, fact-checking, and editing a professional document with AI help, until you had a strong, well-voiced draft sitting inside an AI chat window or a plain text file. That draft is real progress, but it is not yet a finished product. A finished professional document is a file: a Word document you attach to an email, a PDF you upload to a job application portal, or an HTML page you publish somewhere online. Getting from a good draft to a good file is a separate skill from drafting itself, even though you have used Word-like tools and HTML pages throughout this course. This week teaches that skill on its own, because it turns out to matter enormously for a blind or low vision reader, and because employers judge a document partly by whether it arrives in a clean, professional, usable format.

Here is the surprising part, and the reason this week exists at all. A document can read beautifully inside an AI chat window. The headings look like headings. The table lines up neatly. An image has a clear description sitting right next to it in the conversation. And yet, the moment that same content gets exported, downloaded, or "printed" into a Word file, a PDF, or some other format, real problems can appear that were never visible in the chat window itself. A heading that looked bold and large in the chat can turn into ordinary bold text in the exported file, with no actual heading behind it. A table that looked tidy can lose the connection between its header row and its data, so a screen reader can no longer tell you which column you are in. An image that had a perfectly good description in the chat can arrive in the file with no description at all, because the export step did not carry that description along with the picture.

This happens because exporting a document is really a kind of translation. The AI chat window has its own internal way of representing a heading, a list, or a table. The file format you export to, whether that is a Word document, a PDF, or an HTML page, has its own separate system for representing those same things. A good export step translates faithfully from one system to the other. A poor export step does not, and the reader receives a file that looks fine to a sighted person skimming it, but that a screen reader cannot make sense of in the same organized way. Because you cannot always predict, in advance, which export will translate faithfully and which one will not, the only reliable habit is to check the actual finished file yourself, every time, rather than trusting that a good-looking chat window automatically means a good file.

Tagged documents versus visually formatted documents

To check a file for accessibility, you need one core idea firmly in mind: the difference between a tagged document and a visually formatted document. A tag, in this sense, is a piece of hidden structural information built into a file that tells assistive technology, such as a screen reader, exactly what a piece of content is. A tag says, in effect, "this is a heading, level two," or "this is a list item," or "this cell is a table header for the column below it." A sighted reader never sees a tag directly. A screen reader depends on tags constantly, because tags are how it knows what it is reading, not just what the words say.

A properly tagged document has four features worth knowing by name, because this week's whole review checklist is built around checking for them. First, it uses real heading styles, meaning an actual "Heading 1," "Heading 2," and so on, applied through the word processor's own style system, rather than text that merely looks bigger and bolder than the paragraph around it. Second, it has a logical reading order, meaning the order a screen reader moves through the content when reading straight through matches the order a sighted reader would naturally follow, even in a document with a sidebar, a callout box, or more than one column. Third, every image that carries meaning has alt text, a short written description attached to the image so a screen reader can announce what the image shows, and every image that is purely decorative is marked as decorative so the screen reader skips it silently instead of announcing something unhelpful like just the word "image." Fourth, every real data table has header rows properly marked, so a screen reader can announce which column and row a cell belongs to as you move through the table, rather than reading a wall of unlabeled numbers and words.

A visually formatted document, in contrast, can look identical to a properly tagged one on a screen, and still be almost unusable with a screen reader. Picture someone selecting a line of text, making the font larger, and making it bold, so it looks exactly like a heading to anyone glancing at the page. To a sighted reader skimming visually, that line reads as a heading. To a screen reader, that line is still just an ordinary paragraph with some extra visual styling attached to it, because no actual heading tag sits behind it. A screen reader user who presses a heading-navigation key to jump quickly through a long document will sail right past that line without even knowing it was meant to stand out, because there is nothing in the file's structure marking it as a heading, only in its appearance. The same trap applies to tables built by lining up text with extra spaces or tab characters instead of a real table structure, and to images pasted in with no description attached at all. In every one of these cases, the visual result can look identical to the properly tagged version. The difference lives entirely underneath the surface, in tags a sighted person never notices and a screen reader depends on completely.

This is exactly why this week matters so much for you personally, and for every blind or low vision reader who receives a document from you. A hiring manager who glances at your resume for three seconds does not care whether your section headings are "real" headings or just bold text; it looks the same to them either way. But if that same resume later gets read into an applicant tracking system, summarized by an AI tool, or opened by a colleague using a screen reader, the difference between tagged and visually formatted can be the difference between a document that works and one that does not. Producing a properly tagged file is not a courtesy extra; it is what makes a document actually functional for every reader, not just a sighted one glancing at a screen.

A durable way to check a Word document's accessibility

Most mainstream word processors, including the ones you have likely used or seen described earlier in this course, build in an accessibility checker: a feature that scans a document and flags likely problems, such as an image with no alt text, a heading level that gets skipped, or a table with no header row set. This is genuinely useful, and this lesson wants you to know it exists and know how to find it. What this lesson will not do is hand you one exact menu path, one exact button name, or one exact keystroke sequence and promise it will always be correct, because word processor interfaces change over time as they get updated, in ways this lesson cannot predict for whichever version you happen to be using when you read it. Instead, this lesson teaches you a durable method for finding the checker yourself, the same exploration approach used earlier in this course for every interface that changes over time.

The first tool in that method is your screen reader's own structure-browsing feature. Many screen readers offer a list of links or interactive elements (sometimes called an elements list), along with separate ways to browse just the headings or just the tables in a document. In many applications, including word processors, these features let you view a filtered list of just the headings, just the tables, or just the links in the current document, switching between those categories one at a time. Exactly which key or key combination opens this feature depends on which screen reader you use, so check your own screen reader's shortcuts rather than expecting one fixed command to work everywhere. You do not need an official accessibility checker at all to catch a large share of problems this way. If you open your screen reader's list of headings and hear only one heading where you expected three, that tells you immediately that two of your intended headings never actually became real heading tags, no matter how they looked on screen.

The second tool is ordinary menu navigation using the keyboard alone. Pressing Alt typically opens the application's menu or ribbon area, after which the arrow keys move focus between menu items and your screen reader announces each one aloud as you go. Many mainstream word processors group an accessibility checker somewhere near a "Review" area or inside a "File" or document-information area, but rather than memorize that as a permanent fact, treat it as a starting guess, and let your ears, not your memory of an old screenshot, confirm where it actually lives in whatever version you are using. Listen for wording such as "Check Accessibility," "Accessibility," or something close to it as you move through the menu structure.

The third tool, and often the fastest one, is the application's own search or help feature. Nearly every modern application includes some kind of text box, reachable by keyboard, where you can type what you are looking for in plain words and jump straight to that feature, without needing to know which menu it lives under at all. Typing a search term such as "accessibility" or "check accessibility" into that box is frequently the quickest, most future-proof way to reach the checker, because it does not depend on you remembering this month's menu layout.

Once you find the checker and run it, most versions produce a results list you can read the same way you would read any other list: with Say All, or your screen reader's continuous reading command, or by moving item by item and letting your screen reader announce each finding. Each item usually explains what the problem is, such as a missing image description, and many versions also offer a suggested fix you can apply directly from that same list. If you genuinely cannot locate a checker in a particular application at all, that is not a dead end. Everything this lesson teaches, your screen reader's list of headings and other elements, careful heading and table navigation, and the five-point checklist later in this section, works as a complete accessibility check entirely on its own, with or without a built-in checker feature.

Tagged PDFs, and why "print to PDF" can go wrong

A tagged PDF is a PDF file that carries the same kind of structural information described earlier in this lesson, heading levels, a defined reading order, alt text on images, and header rows on tables, inside the PDF's own internal tagging system. A screen reader opening a properly tagged PDF can navigate it almost exactly the way it navigates a well-tagged Word document or a well-built webpage: jumping between headings, moving through a table cell by cell with header announcements, and hearing image descriptions where they matter.

An untagged PDF looks identical to a tagged one on a screen. The text is visible, the layout looks normal, and a sighted reader would never guess anything was wrong just by looking at it. But an untagged PDF has no structural tags underneath that visible text at all. A screen reader opening an untagged PDF may have no reliable way to tell where a heading begins, may read a multi-column layout in the wrong order, may skip past images with zero description, and in the worst case, if the PDF is actually a scanned image of text rather than real selectable text, a screen reader may be unable to read any of the words at all.

The feature usually labeled "print to PDF," or a similar "export as PDF" option, including inside an AI chat tool's own "download as PDF" feature, can sometimes produce an untagged PDF rather than a tagged one. This happens for a simple reason: a PDF export step can generally only carry over the tags that already existed in the original content. If the original document was already properly tagged, with real headings, a real reading order, and real table headers, a good PDF export tends to preserve that structure faithfully. If the original document was only visually formatted to begin with, no export step can invent tags that were never there, and the resulting PDF often comes out untagged no matter how good the export tool is. In short, the PDF export step usually cannot fix a structure problem; it can only preserve or fail to preserve whatever structure already existed before export.

That gives you a genuinely durable strategy, one that does not depend on any specific tool's current button names. Fix the structural problems in the original Word document first, confirm the fix using your screen reader's heading and table navigation and the built-in checker described in the previous section, and only then export that already-clean document to PDF. Trying to fix a PDF's tagging directly, after the fact, tends to be far more difficult than fixing the source document and re-exporting it, so treat PDF export as the last step, not a place to patch up structural problems.

You can also put an AI tool to work here directly, as long as you understand its real limits. You can ask an AI tool that generated a document for you to "export this as a tagged, accessible PDF with real heading styles and header rows on any tables," and a capable tool will often follow that instruction more carefully than if you had not asked at all. What an AI tool typically cannot do reliably is inspect a finished PDF file after the fact and tell you with certainty whether its internal tags are actually correct, because confirming a file's real internal tag structure is a different task from writing the text in the first place. Use the AI tool's help at the writing and export-instruction stage, and then independently verify the result yourself, using your screen reader's own navigation inside a PDF reader or browser, applying the same verification habit you built earlier in this course: check AI output rather than trust it automatically.

Producing accessible HTML as a third option

Word and PDF are not the only formats worth knowing. Clean, accessible HTML is a genuinely strong third option, and it is one where you already have a real head start, because earlier lessons in this course taught you the building blocks of HTML structure directly. Unlike exporting from a chat window into Word or PDF, where an unpredictable translation step sits between your content and the final tags, writing or requesting HTML output lets you, or an AI tool working from your clear instructions, place the actual tags directly, with nothing lost in translation along the way.

The core HTML techniques involved are stable and standardized, which is exactly why this lesson can describe them concretely instead of hedging the way it hedges about menu paths. Headings use the elements h1 through h6, in order, without skipping a level, the same rule this course's own pages have followed every single week. Lists use ol for a numbered list or ul for a bulleted list, with each item wrapped in an li element. Tables use th elements for header cells, each carrying a scope attribute, scope="col" for a column header or scope="row" for a row header, so a screen reader can announce exactly which header applies to each data cell as you move through it. Images use an alt attribute holding a short description for any image that carries meaning, or an empty alt="" for a genuinely decorative image, which tells a screen reader to skip it silently instead of guessing at a description that was never provided.

Because you already understand these tags from earlier lessons in this course, you are in an unusually strong position to ask an AI tool for HTML output directly and then genuinely evaluate what comes back, rather than simply trusting it. You can ask an AI tool to "produce this document as clean HTML with real heading tags, a real list, and a real table with scoped header cells," and then check its answer the exact same way this entire course has checked HTML all along: opening your screen reader's list of headings, using your screen reader's heading navigation, using its table navigation, and reading straight through with Say All, or your screen reader's continuous reading command, to confirm the reading order makes sense.

HTML is not a universal replacement for Word or PDF, and this lesson will not pretend otherwise. Some employers, application systems, and colleagues specifically expect a Word document or a PDF, and an HTML file will not satisfy that requirement no matter how well built it is. Treat HTML as one strong option among three, especially useful when you have full control over how a document will be delivered, such as a personal portfolio page, a document you are sending directly to someone by email as a webpage, or a working draft you want to check thoroughly before converting it into whichever format a particular employer actually asked for.

A practical review checklist before you send anything

Whichever format you end up with, Word, PDF, or HTML, run the same five-point checklist against the finished file before you send it to anyone. This checklist is deliberately format-independent, because the underlying ideas, tagged headings, tagged tables, described images, no color-only meaning, and a sensible reading order, apply identically no matter which of the three formats you chose.

First, check that heading levels are correct: one clear title, no skipped levels, and every section that should be a heading is actually tagged as one, not just made to look larger or bolder. Confirm this with your screen reader's list of headings, or with heading navigation in a browser for HTML.

Second, check that tables have header cells properly marked, so a screen reader announces the right column and row information as you move through each cell, rather than reading unlabeled data with no context.

Third, check that every image either has real alt text describing what it shows, when that image carries meaning, or is properly marked as decorative, when it does not, so it gets skipped silently instead of interrupting the reading experience with nothing useful to say.

Fourth, check that no information depends on color alone. If red text marks something urgent, or a green highlight marks something approved, make sure that same meaning is also carried in the actual words, since a screen reader does not announce color, and a low vision reader using a high-contrast or monochrome display setting may not reliably perceive it either.

Fifth, check that the reading order matches the visual order. Read the whole document straight through with Say All and listen for anything that arrives out of place, such as a caption announced after the table it belongs to instead of before it, or a sidebar note interrupting the middle of a paragraph it has nothing to do with.

Running this checklist takes a few minutes once it becomes a habit, and it is worth running on the actual exported file, not only on the draft sitting inside the AI chat window, for exactly the reason the opening of this lesson explained: the export step itself is where a clean-looking draft most often picks up new problems.

Worked example: reviewing a short sample document

Applying the checklist to one concrete example usually makes it click faster than reading the five points alone. Picture a short, one-page meeting summary an AI tool helped draft: a title, two section headings, a small table of action items with an owner and a due date, and one chart image showing project progress. Here is what running the five-point checklist against the exported file actually found, and how each problem was fixed.

Heading levels: opening your screen reader's list of headings produced only one result, even though the document clearly looked like it had a title and two section headings. That meant one of the two section headings had only been made larger and bold by hand, never given a real heading style. The fix was to select that line and apply a genuine Heading 2 style through the word processor's own style system, so the list of headings then correctly listed all three headings.

Table headers: navigating into the action items table and arrowing across the first data row produced no column announcement at all, meaning the first row had never been marked as a header row, even though it visually looked like a header because it was bold. The fix was to select that first row and explicitly mark it as a table header row, after which arrowing across the table correctly announced "Owner" and "Due Date" for each relevant cell.

Image description: the chart image had no alt text at all, so a screen reader announced only "image" with no other information, even though the chart conveyed a real, meaningful trend in the project's progress. Because this image carried genuine meaning rather than being purely decorative, the fix was to write a short, accurate description of what the chart actually showed and attach it as the image's alt text, rather than leaving it blank or marking it decorative.

Color-only meaning: the action items table used red text to flag overdue items, with nothing else marking them as overdue. Since a screen reader does not announce text color, and a low vision reader using certain display settings might not reliably perceive red either, the fix was to add the actual word "Overdue" next to each affected item, so the meaning lived in the words themselves, not only in a color choice.

Reading order: reading the whole document from top to bottom with Say All revealed that the table's short caption, meant to introduce what the table showed, was actually announced right after the table instead of before it, because of how the content had been arranged during drafting. The fix was to move that caption text ahead of the table in the underlying structure, so a reader hears the context first, exactly as a sighted reader glancing at the page would expect.

After all five fixes, running the checklist again from the top found no remaining issues. Notice what this worked example actually shows: finishing the job on an already-drafted document is rarely one dramatic rewrite. It is five small, specific, checkable corrections, found by actually running the checklist against the real exported file, not by guessing or by trusting that a good-looking draft automatically produced a good file.

Where this fits in the bigger picture

Earlier lessons in this course gave you a document worth sending. This week gave you the tools to make sure that document genuinely works once it becomes a real file, in whichever of the three formats, Word, PDF, or HTML, an employer or colleague actually expects to receive. Notice that almost nothing in this lesson depended on one specific, current version of any single application. The concepts, tagged headings, reading order, alt text, real tables, a tagged PDF, and clean HTML, are stable ideas that outlast any particular menu layout, and the exploration method, your screen reader's list of headings and other elements, careful keyboard menu navigation, and an application's own search feature, is the same durable habit this course has taught you to rely on from early on. That is precisely what makes this week's skill so transferable: whatever word processor or PDF tool you are using five years from now, this same checklist and this same exploration method will still work.

Key terms from this week

Use this list to review the vocabulary introduced in this lesson before you start the exercises and the test.

Tagged document: A document with hidden structural information built in: real heading styles, a logical reading order, alt text on meaningful images, and real data tables with header rows, which together let a screen reader understand what it is reading, not just the words themselves.
Visually formatted document: A document that looks correctly structured to a sighted reader, such as bold, larger text standing in for a heading, but that has no real tags behind that appearance, so a screen reader cannot recognize the intended structure.
Reading order: The order in which a screen reader moves through a document's content, which should match the order a sighted reader would naturally follow, but which can drift out of place in a poorly tagged file.
Alt text: A short written description attached to an image so a screen reader can announce what the image shows, used for any image that carries real meaning rather than being purely decorative.
Tagged PDF: A PDF file that carries structural tags, such as heading levels, a defined reading order, alt text, and table headers, inside its own internal tagging system, so a screen reader can navigate it in an organized way.
Untagged PDF: A PDF file with no structural tags underneath its visible text, which can leave a screen reader unable to identify headings, table structure, or images, even though the file looks normal on screen.

Keyboard-only exercises

These exercises use only your keyboard. Screen reader commands are described in general terms below; substitute your own screen reader's equivalent command where needed.

Exercise 1: Check a Word document's heading structure and find its accessibility checker

Open a Word document you have written or drafted with AI help, such as a professional document you already drafted, in your word processor.
Open your screen reader's list of headings, tables, or links (sometimes called an elements list). Check your own screen reader's shortcuts for the exact keystroke.
Move to the category that lists headings, and use Say All, or your screen reader's continuous reading command, or arrow through it one item at a time, to hear every heading your screen reader has found in the document.
Count the headings your screen reader announces and compare that count against the number of section headings you can see or remember writing. If the numbers do not match, note which heading is missing; that heading was likely made bold and larger by hand rather than given a real heading style.
Close that list and return to the document.
Press Alt to enter the application's menu or ribbon area, then use the arrow keys to move between items, listening to what your screen reader announces for each one.
Explore for an item related to checking accessibility, listening for wording such as "Check Accessibility" or "Accessibility." If your application has its own search or help box, you may instead type a search term such as "accessibility" into that box and let it take you directly to the feature.
Once you locate the checker, run it, and use Say All, or your screen reader's continuous reading command, to listen to its full results list.
Write down, in a new plain text file, every issue the checker reported, in your own words.

Exercise 2: Check an HTML document's structure in a web browser

Open a web browser and navigate to any HTML document you have created or one you produced with AI help, such as a document exported as clean HTML.
Open your screen reader's list of headings, tables, or links (sometimes called an elements list) while the page has focus.
Check the headings category first, confirming the heading levels appear in a logical order with no level skipped, such as jumping straight from a Heading 1 to a Heading 3.
Close that list, then use your screen reader's table navigation (in browse mode, this is often a single letter such as T; check your own screen reader's shortcuts) to jump directly to the first table on the page, if one exists.
Arrow across the table's cells and listen for your screen reader announcing a column header, such as "Owner" or "Due Date," as you move into each data cell.
Use your screen reader's graphic or image navigation (in browse mode, often a single letter such as G) to jump to the next image on the page, and listen to whether your screen reader announces a real description or simply the word "image" or "graphic" with nothing else.
Use Say All, or your screen reader's continuous reading command, to hear the entire page read from top to bottom, listening specifically for anything announced out of the order you expected, such as a caption or note appearing in the wrong place.

Exercise 3: Run the five-point checklist against a finished document

Open a finished, exported document you have already produced, in whichever format you produced it: Word, PDF, or HTML.
Using your screen reader's list of headings or its heading navigation, check heading levels are correct, with no skipped level and no missing heading.
Check that any table in the document has header cells that announce correctly as you move across it, using the method from Exercise 2.
Check that every image either has a real, accurate description or is properly marked decorative, listening for what your screen reader announces at each image.
Read through the document's content and identify anywhere meaning depends only on color, such as red text marking something urgent with no other label, and note it for correction.
Use Say All, or your screen reader's continuous reading command, to read the whole document start to finish, and note anywhere the reading order does not match what you expected visually or from memory.
Save your notes from steps 2 through 6 in a new plain text file named document-accessibility-checklist-notes, listing each problem you found, ready to use in this week's portfolio project.

Portfolio project: My Accessible Document Package

This week's portfolio piece finishes the job of turning a strong draft into a genuinely accessible file. Using a document you have already drafted and critically edited, or a new short document if you prefer to start fresh, you will produce it in at least two of the three formats covered this week, check each one for accessibility, and fix at least one real problem you find.

Choose the document you will finish: a document you have already drafted, or a new short professional document of your own, such as a one-page summary, a short report, or a resume section.
Produce the document in at least two of these three formats: Word, PDF, or HTML.
For each format you produced, run the five-point review checklist from this week's lesson: heading levels correct, tables have header cells, images have alt text or are marked decorative, no color-only meaning, and reading order matches visual order. Use your screen reader's list of headings and other elements, keyboard navigation, and Say All, or your screen reader's continuous reading command, to check each point, the same way you practiced in this week's exercises.
Find at least one genuine accessibility problem in at least one of your formats, and fix it. If you honestly cannot find a real problem after a careful check, deliberately introduce and then fix a small, clearly labeled example, such as an image with no description, so your package still demonstrates the full check-and-fix process.
Write a short note, three to six sentences, describing exactly what you checked in each format and exactly what you found and fixed. Save this note as a plain text file.
Save all of the finished files, in every format you produced, together with your note, in a single folder named my-accessible-document-package, in your portfolio folder.

Before you consider this project finished, confirm each item on this completion checklist:

The document exists in at least two of the three formats: Word, PDF, or HTML.
You ran the full five-point checklist against every format you produced.
You found and fixed at least one real accessibility problem, or deliberately demonstrated the check-and-fix process if none was found.
Your short written note clearly describes what you checked and what you fixed.
All finished files and your note are saved together in your portfolio folder.

Weekly test

This test has 50 questions: 30 multiple choice questions, 15 true or false questions, and 5 short answer questions. Every question can be answered using this week's lesson. A score of 38 correct answers out of 50 is a pass. For multiple choice and true or false questions, choose one answer per question. For short answer questions, type a brief answer in your own words.

Part A: Multiple choice (Questions 1 to 30)

Choose the one best answer for each question.

Question 1. According to the lesson, what can happen to a heading when a document reads perfectly in an AI chat window but is then exported to a file?

It can become plain bold text with no real heading tag behind it

It always stays a perfectly tagged heading no matter what

It automatically deletes itself from the file

It turns into an image with no text at all

Question 2. According to the lesson, what can happen to a table's header association during a poor export?

The table always gains extra header rows it did not have before

The table can lose the connection between its header row and its data, so a screen reader cannot tell which column it is in

The table becomes a heading automatically

The table's data disappears completely and cannot be recovered

Question 3. According to the lesson, what can happen to an image's description during a poor export, even if the AI wrote a good one in the chat?

The image always keeps its description perfectly in every case

The image turns into a table automatically

The image can arrive in the file with no description at all

The image becomes a heading with no picture

Question 4. According to the lesson, why does exporting a document sometimes lose structural information?

Exporting always deletes all text content from the document

Exporting only works for documents shorter than one page

Exporting requires a paid subscription to work correctly

Exporting is a kind of translation between two different systems for representing headings, lists, and tables, and the translation is not always faithful

Question 5. According to the lesson, what is the only reliable habit for knowing whether an exported file is accessible?

Checking the actual finished file yourself, every time, rather than trusting a good-looking chat window

Assuming every export is accessible if the chat window looked good

Asking a friend who has never used a screen reader to glance at it

Never exporting any document at all

Question 6. According to the lesson, what is a tag, in the sense this week's lesson uses the word?

A visible label printed at the top of every page

A piece of hidden structural information built into a file that tells assistive technology what a piece of content is

A type of image file format

A password used to open a protected document

Question 7. According to the lesson, what are the four features of a properly tagged document named in this week's lesson?

A cover page, a table of contents, page numbers, and a watermark

A signature line, a date stamp, a logo, and a footer

Real heading styles, a logical reading order, alt text on meaningful images, and real data tables with header rows

Bright colors, large fonts, animated text, and background music

Question 8. According to the lesson, what does a real heading style mean, as opposed to a heading that only looks like one?

Any text that is centered on the page

Any text typed in capital letters

Any text that appears at the very top of a page

An actual "Heading 1," "Heading 2," and so on, applied through the word processor's own style system, not just larger, bolder text

Question 9. According to the lesson, how should a purely decorative image be marked?

Marked as decorative, so the screen reader skips it silently instead of announcing something unhelpful

Given the longest possible written description available

Deleted from the document entirely with no record

Left completely unmarked so the screen reader guesses

Question 10. According to the lesson, why does the difference between tagged and visually formatted documents matter for a resume you send to an employer?

It matters only for documents longer than fifty pages

The resume might later be read by an applicant tracking system, summarized by AI, or opened with a screen reader, where the difference becomes functional, not just cosmetic

It never matters, since employers only ever look at documents for three seconds

It only matters if the resume is printed on colored paper

Question 11. According to the lesson, why does this lesson avoid giving one exact menu path for a word processor's accessibility checker?

Because menu paths are considered a trade secret

Because only paid versions of software include a checker

Because word processor interfaces change over time as they get updated, in ways the lesson cannot predict for every future version

Because accessibility checkers do not actually exist in any word processor

Question 12. According to the lesson, what is the first tool described for finding accessibility problems in a document yourself?

A printed manual that ships with the software

A telephone call to customer support

A magnifying glass icon in the corner of the screen

Your screen reader's own list of headings, tables, and links (sometimes called an elements list)

Question 13. According to the lesson, where do many mainstream word processors group an accessibility checker, described as a general starting guess rather than a permanent fact?

Somewhere near a Review area or inside a File or document-information area

Inside the printer settings dialog exclusively

Only inside a separate paid add-on purchased separately

Inside the desktop's system clock settings

Question 14. According to the lesson, what is often the fastest, most future-proof way to find a specific feature like an accessibility checker?

Waiting for the next software update before trying again

Typing a search term such as "accessibility" into the application's own search or help box

Reinstalling the entire application from scratch

Calling a friend and asking them to read the whole screen aloud

Question 15. According to the lesson, what should you do if you genuinely cannot locate a built-in accessibility checker in a particular application?

Refuse to use that application ever again

Give up on checking the document's accessibility entirely

Rely on your screen reader's structure-navigation tools, careful heading and table navigation, and the five-point checklist, which work as a complete check on their own

Assume the document must already be perfectly accessible

Question 16. According to the lesson, what is a tagged PDF?

A PDF that can only be opened with a special paid app

A PDF that has been digitally signed for security

A PDF with a watermark stamped on every page

A PDF that carries structural information, such as heading levels, reading order, alt text, and table headers, inside its own internal tagging system

Question 17. According to the lesson, what does an untagged PDF look like to a sighted reader compared to a tagged PDF?

It looks identical; a sighted reader would never guess anything was wrong just by looking at it

It always displays a warning banner across the top of the page

It always appears blank with no visible text at all

It automatically opens in a different color scheme

Question 18. According to the lesson, what is the worst case an untagged PDF can create for a screen reader user?

The document opens in a much larger font size than intended

If the PDF is actually a scanned image of text, a screen reader may be unable to read any of the words at all

The screen reader reads the document twice as fast as normal

The screen reader automatically translates the PDF into a different language

Question 19. According to the lesson, why can a "print to PDF" or "export as PDF" feature sometimes produce an untagged PDF?

Because PDF export only works for documents under one page

Because PDF files are never able to hold any tags under any circumstances

A PDF export step can generally only carry over tags that already existed in the original content

Because "print to PDF" always deletes every tag on purpose

Question 20. According to the lesson, what is the durable, tool-independent strategy recommended for producing a well-tagged PDF?

Convert the PDF into an image before sending it to anyone

Always fix problems inside the finished PDF file directly, never in the source document

Skip checking the source document and rely entirely on the PDF reader to fix it

Fix structural problems in the original Word document first, confirm the fix, and only then export that already-clean document to PDF

Question 21. According to the lesson, what can an AI tool reliably help with regarding a tagged PDF, and what can it typically not do reliably?

It can follow an explicit instruction to export with real headings and header rows, but it typically cannot inspect a finished PDF's actual tags with full certainty

It can always guarantee a PDF is perfectly tagged with total certainty every time

It can physically print the PDF onto paper by itself

It can only work with PDFs that are under one page long

Question 22. According to the lesson, why is clean HTML described as a genuinely strong third option for output?

Because HTML is the only format any employer will ever accept

You already have a head start from HTML skills built earlier in this course, and writing HTML avoids the unpredictable translation step involved in exporting to Word or PDF

Because HTML documents are always shorter than Word documents

Because HTML cannot contain any images at all

Question 23. According to the lesson, which HTML elements are used for headings, and in what order should they be used?

Elements p1 through p6, used in reverse order

A single element called "title" used for every heading

Elements h1 through h6, used in order without skipping a level

Elements b1 through b6, used in any order at all

Question 24. According to the lesson, which HTML elements are used for a numbered or bulleted list?

table for every kind of list, numbered or bulleted

img for a bulleted list and alt for a numbered list

h1 for a numbered list and h2 for a bulleted list

ol for a numbered list or ul for a bulleted list, with each item wrapped in an li element

Question 25. According to the lesson, what attribute on a th element tells a screen reader whether it is a column header or a row header?

The scope attribute, set to scope="col" or scope="row"

The color attribute, set to a specific hex code

The alt attribute, set to a written description

The size attribute, set to a font measurement

Question 26. According to the lesson, is HTML described as a universal replacement for Word or PDF?

Yes, because Word and PDF are being phased out entirely

No, some employers and systems specifically expect a Word document or a PDF, and HTML will not satisfy that requirement

No, because HTML cannot be read by any screen reader

Yes, HTML always satisfies every possible document requirement

Question 27. According to the lesson, how many points does this week's practical review checklist have?

Ten

One

Five

Two

Question 28. According to the lesson, what is the third checklist point?

Every image must include the photographer's name

Every image must be converted to black and white

Every image must be placed at the very top of the page

Every image either has real alt text or is properly marked as decorative

Question 29. According to the lesson, what is the fourth checklist point?

No information depends on color alone

Every heading must be a different color

The background must always be white

Every link must be underlined in red

Question 30. According to the lesson, what is the fifth checklist point?

Every table must have exactly four columns

The reading order matches the visual order

The file size must be under one megabyte

The document must be signed by a notary

Part B: True or false (Questions 31 to 45)

Choose True or False for each statement.

Question 31. True or False: A document that reads perfectly in an AI chat window is guaranteed to be accessible once it is exported to a file.

True

False

Question 32. True or False: Real heading styles are different from text that has only been made larger and bolder by hand.

True

False

Question 33. True or False: A tagged document has a logical reading order that matches the order a sighted reader would naturally follow.

True

False

Question 34. True or False: According to the lesson, alt text is needed only for images that are purely decorative.

True

False

Question 35. True or False: A real data table has header rows that a screen reader can announce as it moves through the table's cells.

True

False

Question 36. True or False: Your screen reader's own list of headings, tables, and links (sometimes called an elements list) can help you review a document's heading and table structure yourself.

True

False

Question 37. True or False: A tagged PDF preserves structural information such as headings, reading order, and table headers inside its own tagging system.

True

False

Question 38. True or False: According to the lesson, a "print to PDF" or "export as PDF" feature always produces a fully tagged, accessible PDF.

True

False

Question 39. True or False: According to the lesson, you can ask an AI tool to help by requesting that it export a document with real heading styles and header rows.

True

False

Question 40. True or False: According to the lesson, an AI tool can always confirm with full certainty that a finished PDF's internal tags are correct just by being asked.

True

False

Question 41. True or False: In HTML, the th element combined with a scope attribute is used to mark a table header cell.

True

False

Question 42. True or False: According to the lesson, meaning in a document should never depend on color alone.

True

False

Question 43. True or False: According to the lesson, the reading order of a document will always automatically match its visual order with no need to check.

True

False

Question 44. True or False: A screen reader can only announce "heading level two" if the text uses a real heading style, not just bold formatting.

True

False

Question 45. True or False: A visually formatted document relies on appearance alone rather than real structural tags underneath.

True

False

Part C: Short answer (Questions 46 to 50)

Type a brief answer in your own words for each question.

Question 46. According to the lesson, what term describes a document with real heading styles, a logical reading order, alt text, and real data tables with header rows?

Your answer

Question 47. According to the lesson, what should you do instead of memorizing one exact, current menu path for finding an accessibility checker?

Your answer

Question 48. What term describes a PDF that lacks the structural tags a screen reader needs to navigate it in an organized way?

Your answer

Question 49. Name one item from this week's five-point practical review checklist.

Your answer

Question 50. According to the lesson, which two HTML elements can wrap the items of a numbered or bulleted list?

Your answer

Answer key

Each answer below includes a one-sentence explanation drawn from this week's lesson.

Answer key for the Week 15 test, with a one-sentence explanation for every question
Question	Correct answer	Explanation
1	A. It can become plain bold text with no real heading tag behind it	The lesson states a heading that looked fine in the chat window can turn into ordinary bold text once exported, with no real heading behind it.
2	B. The table can lose the connection between its header row and its data, so a screen reader cannot tell which column it is in	The lesson states an exported table can lose the connection between header row and data, so a screen reader can no longer tell which column you are in.
3	C. The image can arrive in the file with no description at all	The lesson states an image can arrive in the exported file with no description, because the export step did not carry the chat description along.
4	D. Exporting is a kind of translation between two different systems for representing headings, lists, and tables, and the translation is not always faithful	The lesson describes exporting as a translation between the chat window's internal structure and the file format's own tagging system, which is not always faithful.
5	A. Checking the actual finished file yourself, every time, rather than trusting a good-looking chat window	The lesson states the only reliable habit is to check the actual finished file yourself every time, rather than trusting the chat window's appearance.
6	B. A piece of hidden structural information built into a file that tells assistive technology what a piece of content is	The lesson defines a tag as hidden structural information that tells assistive technology, such as a screen reader, what a piece of content actually is.
7	C. Real heading styles, a logical reading order, alt text on meaningful images, and real data tables with header rows	The lesson names real heading styles, a logical reading order, alt text on meaningful images, and real data tables with header rows as the four features of a tagged document.
8	D. An actual "Heading 1," "Heading 2," and so on, applied through the word processor's own style system, not just larger, bolder text	The lesson states a real heading style is an actual Heading 1, Heading 2, and so on applied through the style system, not merely larger or bolder text.
9	A. Marked as decorative, so the screen reader skips it silently instead of announcing something unhelpful	The lesson states a decorative image should be marked as decorative so a screen reader skips it silently instead of announcing something unhelpful.
10	B. The resume might later be read by an applicant tracking system, summarized by AI, or opened with a screen reader, where the difference becomes functional, not just cosmetic	The lesson states that although a quick glance looks the same either way, later automated or assistive-technology reading depends on real tags, not appearance.
11	C. Because word processor interfaces change over time as they get updated, in ways the lesson cannot predict for every future version	The lesson explains it avoids memorized menu paths because interfaces change over time, so it teaches a durable exploration method instead.
12	D. Your screen reader's own list of headings, tables, and links (sometimes called an elements list)	The lesson names your screen reader's own list of headings, tables, and links as the first tool for checking a document's structure yourself.
13	A. Somewhere near a Review area or inside a File or document-information area	The lesson names a Review area or a File or document-information area as a general starting guess, not a guaranteed permanent location.
14	B. Typing a search term such as "accessibility" into the application's own search or help box	The lesson recommends typing a search term into the application's own search or help feature as often the fastest, most future-proof method.
15	C. Rely on your screen reader's structure-navigation tools, careful heading and table navigation, and the five-point checklist, which work as a complete check on their own	The lesson states that if no checker is found, your screen reader's structure-navigation tools, keyboard navigation, and the five-point checklist still form a complete accessibility check.
16	D. A PDF that carries structural information, such as heading levels, reading order, alt text, and table headers, inside its own internal tagging system	The lesson defines a tagged PDF as one carrying structural information like heading levels and table headers inside its own tagging system.
17	A. It looks identical; a sighted reader would never guess anything was wrong just by looking at it	The lesson states an untagged PDF looks identical to a tagged one visually, so a sighted reader cannot tell the difference just by looking.
18	B. If the PDF is actually a scanned image of text, a screen reader may be unable to read any of the words at all	The lesson states that if an untagged PDF is really a scanned image of text, a screen reader may be unable to read any of it at all.
19	C. A PDF export step can generally only carry over tags that already existed in the original content	The lesson explains that a PDF export can generally only preserve tags that already existed, so an untagged source produces an untagged PDF.
20	D. Fix structural problems in the original Word document first, confirm the fix, and only then export that already-clean document to PDF	The lesson recommends fixing the source Word document first and exporting only after confirming it is clean, since PDF export usually preserves rather than fixes structure.
21	A. It can follow an explicit instruction to export with real headings and header rows, but it typically cannot inspect a finished PDF's actual tags with full certainty	The lesson states an AI tool can follow explicit export instructions, but confirming a finished PDF's actual internal tags is a different task it typically cannot do with certainty.
22	B. You already have a head start from HTML skills built earlier in this course, and writing HTML avoids the unpredictable translation step involved in exporting to Word or PDF	The lesson explains HTML is a strong option because you already know its structure from earlier lessons, and it skips the unpredictable export translation step.
23	C. Elements h1 through h6, used in order without skipping a level	The lesson states headings use the elements h1 through h6, in order, without skipping a level.
24	D. ol for a numbered list or ul for a bulleted list, with each item wrapped in an li element	The lesson states lists use ol for numbered lists or ul for bulleted lists, with each item wrapped in an li element.
25	A. The scope attribute, set to scope="col" or scope="row"	The lesson states the scope attribute, set to scope="col" or scope="row", tells a screen reader which kind of header a th element is.
26	B. No, some employers and systems specifically expect a Word document or a PDF, and HTML will not satisfy that requirement	The lesson explicitly states HTML is not a universal replacement, since some employers and systems specifically expect Word or PDF.
27	C. Five	The lesson presents a five-point checklist covering headings, tables, images, color, and reading order.
28	D. Every image either has real alt text or is properly marked as decorative	The lesson gives real alt text or a decorative marking for every image as the third checklist point.
29	A. No information depends on color alone	The lesson gives ensuring no information depends on color alone as the fourth checklist point, since a screen reader does not announce color.
30	B. The reading order matches the visual order	The lesson gives matching reading order to visual order as the fifth checklist point.
31	False	The lesson states a document reading well in the chat window does not guarantee an accessible exported file, since export can lose structure.
32	True	The lesson states a real heading style is an actual applied style, not merely text that looks bigger and bolder.
33	True	The lesson defines a logical reading order as matching the order a sighted reader would naturally follow through the content.
34	False	The lesson states alt text is for images that carry real meaning, while decorative images should instead be marked decorative, not given alt text.
35	True	The lesson states a real data table has header rows properly marked so a screen reader can announce column and row information.
36	True	The lesson describes using your screen reader's own list of headings and other elements to check structure directly.
37	True	The lesson defines a tagged PDF as one carrying structural tags like headings and table headers inside its internal system.
38	False	The lesson states this export step can sometimes produce an untagged PDF, especially if the original content was not already tagged well.
39	True	The lesson states you can ask an AI tool to export with real headings and header rows, and a capable tool will often follow that instruction.
40	False	The lesson states an AI tool typically cannot inspect a finished PDF's actual tags with full certainty, so independent verification is still needed.
41	True	The lesson states th elements carry a scope attribute, set to col or row, to mark header cells for a screen reader.
42	True	The fourth checklist point states that no information should depend on color alone, since a screen reader does not announce color.
43	False	The lesson's fifth checklist point specifically warns that reading order can drift out of place and must be checked, not assumed.
44	True	The lesson explains that heading announcements depend on a real heading tag, which bold or larger text alone does not provide.
45	True	The lesson defines a visually formatted document as one that looks structured but has no real tags behind that appearance.
46	A tagged document	See this week's lesson and key terms list for the full definition.
47	Use a durable exploration method: your screen reader's list of headings and other elements, keyboard menu navigation, or the app's own search/help feature	See this week's lesson and key terms list for the full definition.
48	An untagged PDF	See this week's lesson and key terms list for the full definition.
49	Any one of: heading levels correct; tables have header cells; images have alt text or are marked decorative; no color-only meaning; reading order matches visual order	See this week's lesson and key terms list for the full definition.
50	ol or ul for the list, and li for each list item	See this week's lesson and key terms list for the full definition.