Frequently Asked Questions
Find answers about digital accessibility, Section 508, document remediation, accessibility standards, submitting documents, pricing, turnaround times, quality assurance, and using e-508.
Browse by Category
Choose a topic to quickly find the guidance you need.
Accessibility & Section 508
Digital accessibility, Section 508, WCAG, PDF/UA, and accessibility requirements.
Document Remediation
Accessible documents, remediation methods, automation, testing, and validation.
Getting Started with e-508
Submitting documents, native source files, requests, and how e-508 works.
Pricing & Authorization
Quotes, remediation levels, contingency, pricing changes, and approvals.
Turnaround & Delivery
Service levels, completion estimates, delivery packages, and final files.
Quality, Security & Support
Quality assurance, validation, versions, corrections, security, and support.
Accessibility & Section 508
Learn about digital accessibility, Section 508, WCAG, PDF/UA, and requirements that affect accessible electronic content.
Digital accessibility means designing and providing digital content, documents, websites, software, and other information and communication technology so people with disabilities can access and use them.
Section 508 is a United States federal law that establishes accessibility requirements for covered information and communication technology developed, procured, maintained, or used by federal agencies.
The Web Content Accessibility Guidelines, commonly called WCAG, are internationally recognized technical guidelines for making web content more accessible to people with disabilities. The World Wide Web Consortium’s Web Accessibility Initiative develops WCAG through an open standards process. WCAG is organized around four principles: content must be perceivable, operable, understandable, and robust. Each version includes testable success criteria at three conformance levels: A, AA, and AAA. Governments, organizations, developers, designers, and content authors use WCAG to guide accessible design, testing, procurement, remediation, and policy development.
WCAG 2.1 Level AA is a widely used accessibility benchmark that includes all Level A and Level AA success criteria in WCAG 2.1. It addresses barriers affecting people with visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities, with added attention to mobile accessibility, low vision, and cognitive accessibility. Conformance applies to complete web pages and complete processes, rather than selected components alone. WCAG 2.1 Level AA is also the technical standard adopted by the U.S. Department of Justice for state and local government web content and mobile apps under the Americans with Disabilities Act Title II web rule.
WCAG 2.2 Level AA includes every Level A and Level AA success criterion in WCAG 2.2. It builds on WCAG 2.1 and adds criteria that strengthen support for people with cognitive and learning disabilities, people with low vision, and people using mobile devices. New requirements address areas such as visible keyboard focus, alternatives to dragging movements, target size, consistent help, redundant data entry, and accessible authentication. W3C recommends using the latest WCAG version when developing or updating accessibility policies and digital products. A site that conforms to WCAG 2.2 is intended to also conform to WCAG 2.1 and WCAG 2.0.
PDF/UA is the international standard for accessible PDF documents. “UA” stands for Universal Accessibility. The standard defines technical requirements that help assistive technologies interpret a PDF’s content, structure, and reading order. A conforming PDF typically includes a logical tag structure, meaningful headings, alternative text for informative images, correctly identified tables and lists, accessible form fields, document language, and other required metadata. PDF/UA focuses on how accessibility information is represented within a PDF. Organizations may use PDF/UA alongside Web Content Accessibility Guidelines, Section 508 requirements, and human testing to evaluate the usability and accessibility of electronic documents.
An accessible electronic document is a digital file that people with disabilities can read, navigate, understand, and complete using assistive technologies and standard input methods. Depending on the file type, accessibility may require a logical reading order, descriptive headings, meaningful link text, alternative text for images, properly structured lists and tables, sufficient color contrast, accessible form controls, identified document language, and content that does not rely on color alone. Accessibility should be considered when the document is created, reviewed before publication, and verified through automated checks and human evaluation. Common formats include PDF, Word, PowerPoint, Excel, and HTML documents.
An Accessibility Conformance Report, or ACR, documents how well an information and communication technology product or service conforms to specific accessibility standards. An ACR generally identifies the product and version evaluated, the applicable standards, the testing methods used, the conformance level for each requirement, and explanations supporting each finding. Federal buyers often request ACRs during market research and procurement to compare the accessibility of software, platforms, hardware, and digital services. An ACR provides evidence for evaluation, but purchasers should also review its completeness, testing methodology, product scope, date, and supporting remarks before relying on it.
A Voluntary Product Accessibility Template, or VPAT®, is a standardized reporting template created by the Information Technology Industry Council. Vendors use a completed VPAT to produce an Accessibility Conformance Report that explains how a technology product or service supports applicable accessibility standards. Different VPAT editions address standards such as Revised Section 508, Web Content Accessibility Guidelines, and EN 301 549. The blank VPAT is the template; the completed report is the ACR. A useful submission should identify the exact product and version, describe the evaluation methods, provide clear conformance ratings, and include specific remarks for each applicable requirement.
A VPAT is a template, while an ACR is the completed accessibility report. The Information Technology Industry Council publishes the Voluntary Product Accessibility Template, which provides tables and instructions for reporting conformance with accessibility standards. A vendor or evaluator completes the applicable VPAT edition and removes the instructional material to create an Accessibility Conformance Report. The ACR should describe the product evaluated, applicable standards, evaluation methods, conformance findings, and supporting remarks. In procurement, buyers evaluate the completed ACR, rather than the blank VPAT, to understand a product’s documented accessibility strengths, limitations, and testing scope.
Website accessibility monitoring is the recurring evaluation of a website to identify new and unresolved accessibility barriers over time. Monitoring may include scheduled automated scans, manual reviews of key templates and user journeys, document inventory, issue tracking, trend reporting, and validation after fixes or releases. It helps organizations detect regressions caused by content updates, design changes, third-party components, and new functionality. Monitoring works best within a broader governance process that defines ownership, remediation priorities, quality checks, escalation procedures, and reporting. Periodic monitoring supports continuous improvement, but it does not replace comprehensive manual and assistive technology evaluation.
The Americans with Disabilities Act Title II web rule requires state and local governments to make covered web content and mobile apps conform to WCAG 2.1 Level AA, subject to limited exceptions and other provisions in the rule. The requirement applies to content and apps provided directly by a public entity and to covered content provided through contractual, licensing, or other arrangements. Public entities must maintain accessibility as digital content changes. The rule also addresses archived web content, preexisting conventional electronic documents, password-protected documents, individualized documents, linked third-party content, and certain social media posts through specific exceptions and limitations.
The Title II web accessibility rule applies to state and local government entities covered by Title II of the Americans with Disabilities Act. This includes state agencies, counties, cities, towns, public schools, public colleges and universities, public hospitals, courts, law enforcement agencies, transit authorities, libraries, and special district governments. The compliance schedule varies based on population size and whether the organization is a special district government. The rule covers public entities regardless of whether they provide digital services through their own staff, a contractor, a vendor platform, or another arrangement.
The Title II web accessibility rule covers web content and mobile apps that a state or local government provides or makes available, including content delivered through contractors or other arrangements. Covered content can include public websites, online forms, payment portals, meeting information, emergency notices, educational materials, digital services, and mobile applications. The rule contains specific exceptions for qualifying archived web content, certain preexisting conventional electronic documents, content posted by third parties, individualized password-protected documents, linked third-party content, and certain social media posts. Each exception has defined conditions, so public entities should document how they classify and manage exempt content.
The current Title II web accessibility compliance deadlines are April 26, 2027, for public entities with a total population of 50,000 or more, and April 26, 2028, for public entities with a population below 50,000 and for special district governments. These dates reflect the Department of Justice’s 2026 interim final rule extending the original compliance dates by one year. Population is generally based on U.S. Census Bureau data, and special district governments follow the later deadline regardless of population. Organizations should confirm their classification and use the implementation period to inventory content, establish governance, remediate priority barriers, train staff, and implement ongoing testing.
There is no universal scanning frequency that fits every organization. A practical schedule is based on publishing volume, risk, site complexity, legal obligations, and the pace of design or development changes. High-traffic or frequently updated sites may benefit from daily or weekly automated scans, while smaller stable sites may use monthly scans. Organizations should also test after major releases, template changes, content migrations, new third-party integrations, and remediation work. Automated scanning should be paired with periodic manual and assistive technology testing of representative pages and critical user journeys. The goal is a documented monitoring schedule that detects regressions and supports timely remediation.
Agencies can evaluate software accessibility before purchase by defining applicable accessibility requirements in the solicitation, requesting a current Accessibility Conformance Report, and reviewing the report’s scope, product version, testing methods, conformance ratings, and supporting remarks. Evaluators should identify vague or incomplete responses, confirm that the correct standards and VPAT edition were used, and compare documented limitations with the agency’s essential use cases. For higher-risk acquisitions, agencies may request demonstrations, test representative workflows, involve users and accessibility specialists, and include remediation commitments and acceptance criteria in the contract. Accessibility should remain part of market research, source selection, testing, implementation, and contract oversight.
Document Remediation
Understand document accessibility remediation, testing, validation, and the methods available for correcting accessibility barriers.
Document remediation is the process of correcting accessibility barriers in an existing electronic document. Remediation may include repairing the tag structure and reading order, adding alternative text, identifying headings and lists, rebuilding tables, improving color contrast, defining document language, making links meaningful, and ensuring form fields have usable labels and instructions. The work varies by format and complexity. A reliable workflow includes an initial assessment, technical corrections, quality assurance, and validation with automated tools and human testing. Source-file improvements are also important because accessible authoring reduces repeated remediation when documents are updated or republished.
An accessibility audit is a structured evaluation of a website, application, document, or digital product against defined accessibility requirements. A comprehensive audit combines automated testing, expert manual review, keyboard testing, and assistive technology testing. The evaluator documents barriers, maps findings to applicable standards such as WCAG or Section 508, identifies affected pages or components, and provides remediation guidance. Audit scope may include representative page templates, user journeys, forms, multimedia, documents, and reusable components. The resulting report helps an organization prioritize fixes, assign ownership, validate remediation, and establish a measurable accessibility baseline.
Automated accessibility testing uses software to inspect digital content for conditions that can be evaluated programmatically. Tools can identify issues such as missing alternative text, unlabeled form controls, invalid markup, some color contrast failures, empty headings, and certain Accessible Rich Internet Applications (ARIA) errors. Automated testing provides fast, repeatable coverage across many pages and helps teams monitor trends. It cannot determine every WCAG requirement or fully assess usability. Results require review because some findings need human judgment, and some barriers cannot be detected automatically. Strong accessibility programs combine automation with manual and assistive technology testing.
Manual accessibility testing is an expert-led review of digital content using human judgment and defined test procedures. Testers evaluate requirements that automated tools cannot reliably determine, such as whether alternative text communicates an image’s purpose, whether headings reflect the content hierarchy, whether instructions are understandable, and whether a task can be completed using only a keyboard. Manual testing may also examine focus order, error handling, responsive behavior, forms, dialogs, tables, multimedia, and complete user journeys. It complements automated testing and provides the context needed to confirm whether content meets applicable accessibility requirements.
Assistive technology testing evaluates how a website, application, or document works with technologies used by people with disabilities. Examples include screen readers, screen magnifiers, speech recognition software, alternative keyboards, switch devices, and browser zoom. A tester may verify that controls have meaningful names and roles, content is announced in a logical order, keyboard focus is visible, status messages are communicated, forms provide usable instructions and errors, and interactive components can be operated effectively. Assistive technology testing provides important usability evidence and is typically performed alongside standards-based manual and automated testing.
PDF/UA is the international standard for accessible PDF documents. “UA” stands for Universal Accessibility. The standard defines technical requirements that help assistive technologies interpret a PDF’s content, structure, and reading order. A conforming PDF typically includes a logical tag structure, meaningful headings, alternative text for informative images, correctly identified tables and lists, accessible form fields, document language, and other required metadata. PDF/UA focuses on how accessibility information is represented within a PDF. Organizations may use PDF/UA alongside Web Content Accessibility Guidelines, Section 508 requirements, and human testing to evaluate the usability and accessibility of electronic documents.
Accessibility conformance evaluation is the process of determining whether digital content satisfies the requirements of a defined accessibility standard. For web content, an evaluation may assess conformance with WCAG at Level A, AA, or AAA. The evaluator must consider complete pages and complete processes, identify the technologies relied upon, and apply appropriate automated and manual test methods. A conformance evaluation differs from a quick scan because it requires evidence and judgment across all applicable success criteria within the stated scope. The results should clearly describe the evaluated version, sample, methods, findings, limitations, and conformance conclusion.
Pre-publication accessibility testing reviews digital content before it is released to the public or distributed to users. It can be integrated into content approval, software development, document production, and procurement workflows. Typical checks include automated scanning, keyboard review, heading and reading-order verification, alternative text review, color contrast testing, form validation, and checks with assistive technologies. Testing before publication helps teams correct issues while the content and source files are still being developed. It also reduces preventable remediation backlogs and supports consistent accessibility across websites, applications, documents, and communications.
Automated tools cannot confirm full WCAG conformance by themselves. They can test many programmatically determinable conditions and quickly identify recurring patterns across large amounts of content. Many WCAG success criteria require human judgment, context, interaction, or evaluation with assistive technology. For example, software may detect that an image has alternative text, but a person must determine whether the text accurately communicates the image’s purpose. A defensible conformance assessment combines automated testing with manual review, keyboard testing, assistive technology testing, and evaluation of complete user processes. Automated results should therefore be treated as findings and indicators, rather than a complete conformance determination.
Getting Started with e-508
Prepare your files and understand what happens when you submit a document remediation request.
Provide the final document or native source file when available, the requested output format, known accessibility requirements, customer contacts, billing or funding information, and any supporting material needed to interpret charts, forms, diagrams, multimedia, specialized terminology, or other complex content.
Native Word, Excel, and PowerPoint files often contain structure that can be corrected more accurately and efficiently than a flattened PDF. Providing the source can also reduce rework when content changes later.
e-508 evaluates the submitted documents, determines the applicable remediation characteristics, and prepares them for quoting. You can then review the proposed remediation approach, pricing, turnaround, and estimated completion before authorization.
Yes. A request may contain multiple documents. Each document can have its own assessment, remediation level, method, quantity, and pricing while remaining part of the same quote or order.
A remediation level represents the expected accessibility effort and complexity associated with a document. It helps determine the applicable remediation scope and unit price.
You may keep the system-derived level or select a higher permitted level. You may not reduce the document below its system-derived minimum. For example, a document derived as Complex may be increased to Complex Plus but not reduced to Moderate.
e-508 treats the selection as an upward override and recalculates the applicable document price and quote total. The quote retains both the system-derived level and the level selected for pricing.
Eligible documents may be routed through an approved automated-remediation service. Automated processing remains subject to e-508 quality-assurance, security, version-control, and release requirements before a document is delivered to you.
Pricing & Authorization
Learn how estimates, contingency, remediation levels, quote changes, and authorization work.
Pricing generally uses the billable quantity, such as pages, slides, worksheets, or tasks, together with the applicable remediation level, remediation method, unit rate, and any approved add-ons or service-level charges. The active quote is the authoritative pricing record.
Contingency is an amount that may be reserved above estimated base remediation pricing to address document conditions that could not be fully identified during initial assessment. The active quote or contract determines the applicable rate and how contingency is treated.
The quote may change if you select a different turnaround option, choose a higher remediation level, change the remediation method, add or remove documents, or otherwise change the requested scope.
Financial authorization is performed by a user with the appropriate financial-approval authority. Administrative or document-review access does not automatically grant authority to approve financial commitments.
Approval authorizes the displayed scope and pricing to proceed. e-508 records the approved quote version and uses the actual approval date and time to establish the applicable production schedule.
A material change to previously authorized pricing or scope is handled through a controlled modification or revised quote. When required, the revised amount must be reviewed and reauthorized before the additional work proceeds.
Document access and financial authority are separate permissions. A Reviewer, Requester, Administrator, or Read-Only user may have document visibility without authority to approve financial commitments.
The active e-508 quote, applicable contract or task order, approved pricing schedule, and authorized task information take precedence over planning examples or general guidance in the Customer Guide.
Turnaround & Delivery
Understand completion estimates, turnaround options, quality assurance timing, and delivery of final remediated files.
Estimated Completion is the date and time e-508 expects the finished, QA-reviewed work to be ready based on the selected turnaround, the anticipated approval time, and the applicable business calendar.
e-508 applies the selected Standard, Expedited, or Emergency turnaround rule to the effective approval date and time and excludes weekends and configured holidays according to the applicable schedule profile.
The schedule begins at the next eligible business-day start time according to the applicable contract-vehicle schedule rules.
Before authorization, the completion date is an estimate based on when approval is assumed to occur. The estimate can change as time passes or when you select a different turnaround option. The final schedule is established using the actual approval timestamp.
Standard follows the normal production schedule. Expedited shortens the schedule when available, and Emergency provides the shortest configured turnaround for eligible work. Availability, pricing, and specific completion targets are shown in the active quote.
Yes. The customer completion target represents completion of the overall remediation and QA process. Internal remediation staff may have earlier work deadlines so that sufficient time remains for QA, corrections, validation, and release preparation.
Use the latest QA-approved or final remediated version identified by e-508. Earlier files may remain available for historical purposes but should not be substituted for the current approved deliverable.
Completed and authorized deliverables are available through the Remediation Delivery Workspace, together with the associated validation, comments, modification, and history information.
Yes. A change in content, document quantity, complexity, remediation method, or other scope can require a revised production schedule.
Quality, Security & Support
Find guidance on quality assurance, validation evidence, document versions, corrections, secure access, and support
No. Automated tools can identify many technical conditions, but they cannot reliably evaluate every semantic or usability requirement. e-508 uses QA and other applicable validation evidence in addition to automated results.
Validation records are associated with the specific document version that was tested. Confirm that the file name, version, and validation information correspond to the deliverable you are reviewing.
The document is returned for correction and must be reviewed again as appropriate. A corrected document becomes a new version so that QA evidence remains associated with the exact file that was tested.
A document can change after remediation or testing. e-508 maintains version information so that the file approved by QA can be distinguished from earlier or subsequently modified versions.
You may change your own copy, but substantive changes can affect accessibility and invalidate the QA evidence associated with the delivered version. A modified document may require renewed remediation and validation.
A correction addresses remediation work that was already included in the authorized accessibility scope. A modification changes the customer-provided content, source document, requested output, or other approved scope and may affect price and schedule.
e-508 may need to reassess the new version. Depending on the extent of the changes, remediation, pricing, turnaround, or QA may need to be updated.
Use Notes and Comments within the applicable remediation task so feedback remains associated with the correct document, version, page, slide, worksheet, or validation issue.
Identify the issue in the Remediation Delivery Workspace and submit the appropriate correction request or comment rather than modifying the delivered file and returning it outside the system.
Acceptance confirms that an authorized customer user has reviewed and accepted the specified delivered version. It does not automatically apply to later versions created after additional changes.
You can ask a question, provide review comments, or request an appropriate correction or modification rather than accepting the deliverable.
Contact your Customer Administrator or support team. Your role, operating-unit access, or specific approval authority may need to be reviewed.
e-508 uses role-based access, secure transport, protected download mechanisms, and audit logging. Access to sensitive source documents, financial information, or other records may be restricted by role.
No. Read-Only users can view authorized information and permitted deliverables but cannot change task data, submit modifications, post comments, approve pricing, or perform other workflow actions.
Task history can include significant events such as document uploads, assignments, quote approvals, remediation-level changes, QA decisions, validation publication, modifications, downloads, customer acceptance, and closure.
Consequential history should be preserved rather than silently overwritten. When a correction or new event occurs, e-508 records the new event so the sequence of activity remains understandable.
Retention depends on the applicable contract, customer policy, and record type. When available, e-508 should display the applicable retention or archive information so authorized users can retrieve required records before expiration.