Chapter 6 reaches your help centre, your call centre and your training
By David LoPresti March 6, 2023 Open ten Accessibility Conformance Reports for software products and count how many have a filled Chapter 6. In most of them the table is present, three rows long, and every row says Not Applicable, or it says Supports with an empty remark. The product tables above it are detailed. The documentation table reads like a formality somebody cleared on the way to submitting.
That table is not a formality. It is the chapter that reaches your user manual, your online help, your knowledge base, your training material, your help desk and your call centre, and it carries one requirement that is about what you write rather than how you format it.
What follows is what Chapter 6 actually says, provision by provision: which of your artifacts it covers, the content requirement almost nobody has read, the relief that agencies get for documents and this chapter does not repeat, how the European standard asks the same question differently, and what a Chapter 6 table looks like when it is doing its job.
The chapter starts wider than its name
The heading says Support Documentation and Services, which sounds like a manual and a phone number. The scoping sentence is broader than that.
602.1 states it in eleven words:
Documentation that supports the use of ICT shall conform to 602.
Documentation that supports the use. Not documentation you shipped in the box, not documentation you called a manual, not documentation that exists as a file. If a customer uses it to operate your product, it is inside the provision, and the format it happens to take does not remove it.
Applied to a modern software product, that reaches the installation guide, the administrator handbook, the in-product help, the online knowledge base, the release notes a customer needs to configure a feature, the API reference, the onboarding videos, and the PDF one-pager sales left with the buyer. Most of those live in different systems owned by different teams, which is the practical reason Chapter 6 gets marked Not Applicable: nobody in the room owns all of it.
View the data as a table
| Provision | Exact requirement | Reaches |
|---|---|---|
| 602.1 | Documentation that supports the use of ICT shall conform to 602 | Everything a customer uses to operate the product |
| 602.2 | List and explain how to use the accessibility and compatibility features | The content of the documentation |
| 602.3 | Electronic documentation, including web-based self-service support, to WCAG 2.0 A and AA | Manuals, help centres, in-product help, API docs |
| 602.4 | Alternate formats on request where documentation is non-electronic only | Printed cards, boxed guides |
| 603.1 | Help desks, call centres, training services, automated self-service support | The channels, named and open-ended |
| 603.2 | Support services include information on the 602.2 features | What staff know and can explain |
| 603.3 | Provided directly or by referral, accommodating communication needs | The channel itself |
Your help centre, your call centre and your training deck are named
The services half of the chapter is more explicit than most vendors expect. 603.1 names the channels and leaves the list open:
ICT support services including, but not limited to, help desks, call centers, training services, and automated self-service technical support, shall conform to 603.
Four named channels and an open door. A chat widget staffed by humans is a help desk. A ticketing portal is automated self-service technical support. A paid onboarding programme is a training service. An interactive voice response tree is arguably all three.
| Channel | Named in 603.1 | What conformance touches |
|---|---|---|
| Knowledge base or online help | Through 602.3, as web-based self-service | The pages themselves against WCAG |
| Ticketing or support portal | Yes, automated self-service technical support | The portal interface and any documents it serves |
| Live chat | Not by name, reached by “not limited to” | The widget, and whether an agent can answer feature questions |
| Phone support | Yes, call centers | Accommodation of communication needs, and staff knowledge |
| Training, paid or bundled | Yes, training services | Materials, platform, and the trainer’s ability to cover the features |
| Community forum you operate | Not by name, reached by “not limited to” | The platform, where you present it as support |
The distinction that matters when you fill the table is between the interface and the people. Both are in the chapter, and they fail differently.
602.2 asks you to write something, not just to format it
This is the provision that surprises people, and it is the one most Chapter 6 tables are quietly wrong about.
Everything else in the chapter is a conformance requirement: make the artifact meet a standard. 602.2 is a content requirement. It says the documentation:
shall list and explain how to use the accessibility and compatibility features required by Chapters 4 and 5.
And it says which features count: the documentation has to include “accessibility features that are built-in and accessibility features that provide compatibility” with assistive technology.
Read that against your actual help centre. A product with a high-contrast theme, keyboard shortcuts, a screen-reader-tested data grid and a caption track for its tutorial videos has four features that 602.2 wants listed and explained. Most documentation mentions none of them, because accessibility features get documented by the accessibility team in a conformance report rather than by the documentation team in the manual.
The asymmetry is worth stating plainly. You can have a product that conforms, a manual that conforms as a document, and still fail 602.2, because a perfectly accessible PDF that never mentions your keyboard shortcuts has not listed or explained anything.
View the data as a list
- Every built-in accessibility feature, named. High-contrast modes, text resizing, reduced motion, caption support, focus indicators the user can configure.
- How to turn each one on. Not that it exists. The steps.
- Assistive technology compatibility, stated concretely. Which screen readers and browsers the product was tested against, at which versions.
- Keyboard operation. The shortcut list, and how to reach anything that only has a pointer affordance in the default view.
- Known limitations with a workaround. Where a feature is partially supported, the documentation is where a user learns the alternative path.
- Where the support channels are, and which accommodate what. This is where 602.2 and 603.2 meet.
Your knowledge base is a website, and the standard says so
Vendors reason about documentation as documents and about products as software, and Chapter 6 does not respect the split.
602.3 is one sentence with a clause inside it that decides a lot:
Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0.
Including web-based self-service support. Your knowledge base is not adjacent to the standard because it is marketing infrastructure or because a third party hosts it. It is electronic documentation delivered over the web, and it goes to WCAG 2.0 Level A and AA in the same way the product does.
That has a practical consequence for how the row gets tested. A help centre is usually a templated site with hundreds of articles, embedded video, a search interface, code samples and tables. Its failures cluster in the template rather than in the articles: skip links, heading order, focus visibility on the search widget, colour-only syntax highlighting, video without captions. Testing three articles and calling the row Supports is the common shortcut, and it is the one a reviewer with a keyboard finds first.
If the documentation is a pile of files rather than a site, the testing question changes shape, and the federal testing baseline for electronic documents is where the method for that lives.
The relief agencies get for documents is not in this chapter
Here is the sharpest thing in Chapter 6, and it is a reading of the text rather than a settled rule, so it comes with the caveat attached.
The Revised 508 Standards contain a well-known piece of relief for documents. Under E205.4, “Non-Web documents shall not be required to conform to the following four WCAG 2.0” success criteria: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification. Those four are written for sites with many pages, and they translate poorly to a single file. The same provision also supplies a word substitution, replacing “the term ‘Web page’ or ‘page’ appears in WCAG 2.0” with the word document.
That exception sits in E205, which scopes electronic content. It does not appear in Chapter 6. Section 602.3 requires conformance to the Level A and Level AA criteria and the conformance requirements, with no carve-out printed underneath it.
| Agency electronic content, E205 | Support documentation, 602.3 | |
|---|---|---|
| Standard | WCAG 2.0 Level A and AA | WCAG 2.0 Level A and AA |
| 2.4.1 Bypass Blocks on a non-web document | Not required | No exception printed |
| 2.4.5 Multiple Ways | Not required | No exception printed |
| 3.2.3 Consistent Navigation | Not required | No exception printed |
| 3.2.4 Consistent Identification | Not required | No exception printed |
| Word substitution for “Web page” | Provided | Not restated |
The honest position is that this is what the text says and no published guidance resolves whether the E205.4 exception carries across to Chapter 6 documentation. A reviewer is unlikely to fail your report over 2.4.5 in a PDF. A remark that says which reading you applied, and why, is what stops the question from becoming a clarification request.
Paper only means an accessible alternate on request
The shortest provision in the chapter closes a gap that vendors with hardware products still fall into.
Where support documentation exists only in non-electronic form, 602.4 requires that “alternate formats usable by individuals with disabilities shall be provided upon request.” A printed quick-start card in the box, with no digital equivalent, triggers an obligation to produce one when someone asks.
Two things follow. The obligation is reactive rather than prospective, so nothing requires you to convert an archive in advance. And it needs an intake path, because a duty to respond on request implies somewhere for the request to arrive and someone who knows what to do with it. A Chapter 6 row claiming conformance with 602.4 is claiming that path exists.
Support services are in scope, and your staff are the deliverable
The services provisions are short, and they are the two places in the Revised 508 Standards where the thing being measured is a person rather than an interface.
603.2 requires that “ICT support services shall include information on the accessibility and compatibility features” required by 602.2. The same list, in the channel. Whoever answers the phone or the ticket has to be able to tell a caller how to turn on the high-contrast theme, and whether the data grid works with their screen reader.
603.3 addresses the channel itself. Support “shall be provided directly to the user or through a referral to a point of contact”, and it has to accommodate the communication needs of individuals with disabilities. Referral is explicitly allowed, which is the practical route for a small vendor: a documented escalation to someone who can handle a text relay call is conformance, and having no answer is not.
View the data as a table
| Provision | What is being tested | Evidence that satisfies a reviewer |
|---|---|---|
| 602.2 | The documentation’s content | The section of the manual that lists and explains the features |
| 602.3 | The documentation as an artifact | A test record against WCAG 2.0 A and AA, template and articles |
| 602.4 | The intake path for alternates | The published request route and the format you produce |
| 603.2 | What support staff know | The internal reference sheet, and where it lives in onboarding |
| 603.3 | The channel’s accommodation | The relay and referral procedure, named |
The evidence column is the point. Chapter 6 rows are the easiest in the whole report to substantiate, because the proof is a document you either have or do not, and the cheapest to lose, because a row marked Supports with no remark invites the reviewer to ask which page of the manual they should look at.
Training is a support service, and it fails in three places at once
Of the four channels 603.1 names, training is the one vendors least expect to see there, and it is the one where a single engagement can fail the chapter three different ways.
A paid onboarding programme has a platform, materials and a person. The platform is software delivered over the web, so the interface goes to WCAG through the same route as the help centre. The materials are documentation that supports the use of the product, which puts the slide deck, the workbook and the recorded sessions inside 602.3. And the trainer is a support service under 603.2, which means they have to be able to answer a question about the accessibility features the documentation lists.
That last one is where it usually breaks. A trainer who has never turned on the high-contrast theme and does not know which screen readers the product was tested with cannot deliver 603.2, no matter how accessible the deck is. The provision measures knowledge rather than materials, and knowledge lives in onboarding rather than in a file.
| Layer of a training engagement | Provision it lands in | Common failure |
|---|---|---|
| The delivery platform | 602.3, as electronic documentation and web-based support | Video player without captions, no keyboard control |
| Slides and workbooks | 602.3 | Untagged PDF exports, images carrying the only explanation |
| Recorded sessions | 602.3 | No captions, no transcript, no audio description of screen shares |
| Live session conduct | 603.3 | No captioning option, no relay path for a participant who needs one |
| The trainer’s answers | 603.2 | Cannot explain the product’s accessibility features |
Two consequences worth acting on. Recorded training is the cheapest large failure to find, because a recording either has a caption track or it does not, and a reviewer checking your Chapter 6 claim will click one video. And the trainer knowledge requirement is satisfied by a one-page internal reference rather than a programme, which is the highest ratio of conformance to effort anywhere in the chapter.
Where the training itself is the deliverable a customer is buying, accessibility training is a different engagement from the report, and the two overlap here: the material you build to satisfy 603.2 internally is most of what a customer-facing session needs.
The chapter binds the agency, and reaches you through the contract
Worth being precise about who owes what, because it changes how you negotiate rather than what you build.
The scoping provision is written at the buyer. E208.1 provides that “Where an agency provides support documentation or services for ICT”, such documentation and services shall conform to Chapter 6. The subject of that sentence is the agency.
Which is the same structure as the rest of Section 508 and produces the same result. An agency deploying your software provides your documentation to its staff and public, and it cannot satisfy E208.1 with a knowledge base that fails WCAG or a manual that never mentions your accessibility features. So the obligation arrives at your desk through the contract and through the report, and the reason clients ask for a VPAT is the same reason they will ask about Chapter 6 specifically once someone on their side reads the chapter.
Nothing here is a certification. The template’s publisher is explicit that “There is no certification for VPAT.” What exists is a self-disclosure, and what accessibility certification actually exists covers the badges and letters that circulate in place of one.
The European standard asks for one accessible format and the same list
If you sell into the European Union as well, clause 12 of EN 301 549 covers the same ground with two differences that matter when you are producing a single set of documentation for both.
The content duty is the same. Product documentation “shall list and explain how to use the accessibility and compatibility features of the ICT”, built-in and assistive-technology-facing alike.
The format duty is framed differently. Documentation has to be “available in at least one of the following electronic formats”: a web format conforming to clause 9, or a non-web format conforming to clause 10. One accessible format is the requirement, and the standard says explicitly that this does not stop you providing other inaccessible formats alongside it.
| Section 508 Chapter 6 | EN 301 549 clause 12 | |
|---|---|---|
| Feature list and explanation | 602.2 | 12.1.1 |
| Accessible format of documentation | 602.3, all electronic documentation | 12.1.2, at least one accessible electronic format |
| Paper-only documentation | 602.4, alternate on request | Covered by the one-accessible-format rule |
| Support staff feature knowledge | 603.2 | 12.2.2 |
| Communication accommodation | 603.3, directly or by referral | 12.2.3, directly or through a referral point |
| Documentation produced by support | Reached through 602.1 | 12.2.4, stated separately |
Two practical readings. The European framing is easier to satisfy for a vendor with a legacy PDF library, because one accessible format discharges the duty and the old files can stay. And clause 12.2.4 states something Chapter 6 leaves implicit: documentation “provided by support services shall be made available” in an accessible format too, which reaches the PDF a support agent emails a customer at 4pm.
If your product creates content, the documentation duty doubles
One category of product carries an extra layer, and vendors in it routinely file a Chapter 6 table that ignores it.
504.1 sets the trigger: “Where an application is an authoring tool, the application shall conform to 504 to the extent that information required for accessibility is supported by the destination format.” Authoring tool is broader than a word processor. A content management system is one. A form builder is one. An email campaign editor, a report designer, a wiki, a page builder inside your admin panel: each lets a user produce content that somebody else consumes, which is what the definition turns on.
Section 504 then asks four things of the tool itself. It has to provide a mode of operation to create or edit content that conforms to WCAG 2.0 Level A and AA “for all supported features”, while permitting authors to override accessibility information. It has to preserve accessibility information when converting between formats or saving in several. Where it can export PDF 1.7, it has to be capable of exporting PDF/UA-1 as well. It has to prompt authors to create conforming content. And where it ships templates, conforming templates have to be provided for a range of template uses.
Now connect that back to Chapter 6. Section 602.2 requires the documentation to list and explain the accessibility features required by Chapters 4 and 5, and for an authoring tool the Chapter 5 features include all of the above. Which means your manual has to explain where the accessibility-checking mode lives, which templates are the conforming ones, how to export PDF/UA rather than plain PDF, and what happens to alternative text when a user saves to a different format.
| 504 provision | What the tool must do | What 602.2 makes you document |
|---|---|---|
| 504.2 | Offer a mode that produces conforming content | Where that mode is and how to turn it on |
| 504.2.1 | Preserve accessibility data across format conversion | Which conversions preserve it and which lose it |
| 504.2.2 | Export PDF/UA-1 where it exports PDF 1.7 | The export setting that produces the conforming file |
| 504.3 | Prompt authors toward conforming content | What the prompts are and whether they can be disabled |
| 504.4 | Ship conforming templates across a range of uses | Which templates conform, named |
Federal buyer guidance points at the same seam from its own side. Where the item is an authoring tool, the Supplemental Accessibility Report is asked to carry information on how the product enables the creation of accessible content, which is a documentation question dressed as a product question.
The exception is narrow and worth knowing. Authoring tools are not required to conform to 504.2 when used to directly edit plain text source code, so a code editor is out of that particular provision. Nothing in the exception touches the documentation duty.
What a completed Chapter 6 table looks like
The federal edition of the template has four tables, and Chapter 6 is one of them. Guidance says to complete it if your product contains support documentation and services, which for a commercial software or hardware product is almost always.
Which makes Not Applicable a hard claim to defend. A product with a help centre, a manual and an email support address has support documentation and services by any reading, and a row saying otherwise reads as a table nobody looked at.
The rows themselves are short, and the remarks carry the weight. Remarks are not optional where conformance is partial: the guidance requires “remarks, which are required if the product either partially supports or does not support” the criterion. For Chapter 6 that is usually where you say which artifact was tested, because “documentation” covers six things and a reviewer needs to know which of them your answer describes.
View the data as a table
| Row as filed | What a reviewer concludes | Better version |
|---|---|---|
| 602.2 Supports, no remark | Nobody checked whether the manual lists the features | Supports, with the section title and page |
| 602.3 Supports, no remark | The help centre was not tested, or only articles were | Supports, naming the template and article sample tested |
| 602.3 Not Applicable | There is documentation, so this is wrong | Partially Supports, with the template failures named |
| 603.2 Supports, no remark | An assertion about staff with nothing behind it | Supports, referencing the internal feature reference |
| 603.3 Not Applicable | Support exists, so this is wrong | Supports, naming the relay or referral route |
| Whole chapter absent | An incomplete submission | The table, completed |
Who owns the fix when the help centre is somebody else’s product
The awkward case, and it comes up constantly.
Your knowledge base runs on a hosted support platform. Your training sits in a learning management system you license. Your API docs are generated by a tool. In each case the interface belongs to a vendor and the content belongs to you, and 602.3 does not care about that boundary because the buyer experiences one thing.
The workable split is by layer. Content defects are yours: missing alternative text, heading levels used for size, tables without headers, video without captions, colour-only meaning in a diagram. Template defects are the platform’s: focus visibility, skip links, search widget semantics, landmark structure. Yours are fixable this quarter. Theirs need a conformance report from the platform and a roadmap conversation, and asking the platform for its own ACR is the reasonable first move.
What goes in your report is the honest description of both. A remark saying the articles conform, the platform template has two known failures, and the platform’s report is dated is a stronger position than a blanket Supports, because the blanket claim collapses the first time a reviewer tabs through your search box.
Where the content layer is the problem rather than the platform, document and PDF remediation is a different workflow from site work and usually a different team.
What nobody has published
Several things a careful reader would want here do not exist, and naming them is better than filling the space.
No published guidance resolves whether the E205.4 exception for non-web documents carries into Chapter 6. The text puts the exception in E205 and not in 602, and research for this article found no Access Board guidance, no GSA instruction and no decision addressing the question. The safe practice is a remark stating your reading.
Nothing published quantifies how often Chapter 6 rows are filled, skipped or marked Not Applicable across real reports. The observation that opens this article is a pattern anyone who reviews reports will recognise, and it is not a measured figure.
There is no published federal decision on whether an inaccessible vendor knowledge base breaches a contract’s accessibility clause, so what happens after award is a matter of the clause in front of you rather than settled law.
And the boundary between your content and a hosted platform’s template has no authority behind it either. It is a workable engineering split, not a legal one, and a buyer is entitled to treat the whole experience as yours.
Questions vendors ask about Chapter 6
Does Chapter 6 apply if my documentation is only an online help centre?
Yes, and the provision says so directly. 602.3 covers documentation in electronic format “including Web-based self-service support”, which is what a help centre is. The fact that it looks like a website rather than a manual does not move it out of the chapter, and the fact that a third party hosts it does not either. Test the template and a sample of articles, not three articles alone.
Can I mark Chapter 6 Not Applicable?
Rarely, and only where there genuinely is no support documentation and no support service, which is unusual for a commercial product. Federal guidance says to complete the chapter if your product contains support documentation and services. A product with a manual, a help centre or a support address contains both, and a Not Applicable row against a visible knowledge base is the kind of answer that triggers a clarification request rather than passing quietly.
Do the four criteria agencies skip for documents apply to my manual?
The text says the exception lives in E205 and Chapter 6 does not repeat it, so on a plain reading 602.3 requires the full Level A and AA set. No published guidance settles whether that reading is intended. In practice, state your reading in the remark for 602.3, and expect a reviewer to accept a documented position more readily than a silent one.
Is my call centre really in scope?
603.1 names call centers explicitly, alongside help desks, training services and automated self-service technical support, and the list is prefaced with “including, but not limited to”. What conformance means there is not a WCAG audit of a telephone. It is that staff can explain the accessibility features the documentation lists, and that the channel accommodates communication needs directly or through a documented referral.
What does 602.2 actually want me to write?
A section of your documentation that names each built-in accessibility feature and each assistive technology compatibility feature, and explains how to use it. Not a statement that the product is accessible. A list with instructions: how to enable the high-contrast theme, which keyboard shortcuts exist, which screen readers and versions the product was tested with, and what to do where support is partial.
Does a PDF manual have to meet WCAG?
If it is documentation that supports the use of the product and it exists in electronic format, 602.3 reaches it. Tagging, reading order, alternative text, table headers, form fields and language settings are where PDF conformance is usually won or lost. Where a document exists only on paper, 602.4 shifts the obligation to producing an accessible alternate when someone requests one.
What does the European standard want that Section 508 does not?
Two things worth noting. Clause 12.1.2 asks for at least one accessible electronic format rather than conformance across every format, which is easier for a vendor with a legacy library. And clause 12.2.4 states explicitly that documentation produced by support services has to be accessible too, which covers the file an agent emails a customer and which Chapter 6 leaves to be inferred from 602.1.
Who has to fix the help centre, us or our documentation platform?
Split it by layer and say so in the remark. Alternative text, heading structure, table markup and captions are content and belong to you. Focus visibility, skip links, search widget semantics and landmark structure belong to the platform, and the reasonable move is to ask the platform for its own conformance report and record its date in your remark. A buyer will accept a divided answer with evidence more readily than an undivided one without.
Your next step
Take the report you last filed and do three things in order.
First, open the Chapter 6 table and read what it currently claims. If every row says Supports with no remark, or the table says Not Applicable while a public help centre exists, you have found the weakest page in the document and the cheapest one to fix.
Second, answer 602.2 before you test anything. Search your own documentation for the accessibility features your product actually has. If they are not listed and explained anywhere, that is a writing task rather than a testing task, and it is the one part of Chapter 6 no audit will produce for you.
Third, scope the test by artifact rather than by chapter. Name the help centre template, the article sample, the manual and its version, and the support channels, then test each and write the remark against what was tested. A row that names its artifact is a row a reviewer stops asking about.
Where the documentation set is large or the platform is somebody else’s, ADACP’s VPAT and ACR reporting covers the Chapter 6 evaluation and the remarks that go with it, and accessibility remediation is where the content layer gets fixed.