Section 508 in the Digital Space

- Plan
- Gather
- Design
- Develop
- Test
- Deploy
- Operate & Maintain
These seven steps are considered the phases of the development process according to the Section 508 website.¹ When viewed in a more general context, these same steps can apply to the lifecycle of any entity in the digital space: websites, mobile apps, PDF content, videos, etc.
As accessibility conformance effective dates loom closer on more recently passed laws in the US² and globally³, it is vital that {audiences} begin to take actionable steps to removing barriers in information and communication technologies.
Planning for Accessibility
Potentially the most important, time consuming and yet also confusing step is determining where to start. The ideal scenario would be having a strong lead who is familiar with accessibility as it pertains to digital content. If that coordinator role doesn’t exist yet, review if someone in-house would be capable and interested or if a third-party would need to be hired – either for just facilitating or for handling the entirety of the compliance project. If keeping everything in-house, ensure there is ample time for any initial research regarding digital accessibility rules and requirements that may need to be performed as well as any potential hiring of other team members.
The ADA has a great starting point if you’re a state or local government. In a slight summation and paraphrasing some of the key points are as follows:
- Learn the rules and requirements
- Determine when compliance need to be met
- Team roles and responsibilities
- Train staff
- Identify content or mobile apps and their compliance needs
- Determine fixes necessary and their priority
- Work with any outside vendors to see if they need to provide you accessible content
- Create policies
By laying a strong foundation with proper planning, organizations position themselves to meet accessibility goals more efficiently. Identifying roles, responsibilities, and legal obligations early—alongside auditing existing content and building a roadmap—ensures that accessibility isn’t a last-minute task, but a core consideration integrated throughout the digital project lifecycle.
Accessibility Requirements
WCAG Overview
The Web Content Accessibility Guidelines, also known as WCAG, is the technical standard that sets compliance requirements for digital content. WCAG is continuously updated as best practices continue to evolve and is currently on version 2.2, however version 2.1 is the state and local government requirement. The guidelines are divided into levels of conformance: Level A, AA and AAA, with AA being required for government. There are four principles to WCAG often known as POUR. Each of the different levels contain the guidelines pertaining to these principles.⁴
P – Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
O – Operable: User interface components and navigation must be operable.
U – Understandable: Information and the operation of the user interface must be understandable.
R – Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
Auditing
When identifying compliance needs and determining fixes and their priorities of an existing digital property, an initial evaluation of the digital content to determine where the issues are is a critical step. Auditing your existing site or app for current conformance will determine where there are accessibility issues and provide the documentation necessary for beginning to address prioritization and remediation.
In terms of evaluating an existing website, there are a few options. One would be to hire a third-party service or platform that runs accessibility testing. These tests could be an automated, full website scan of all content/pages, testers performing automated and manual evaluations as well as testing done by users with disabilities. If auditing in-house, there are a number of free automated tools to check for accessibility issues while in the web browser such as WAVE, axe DevTools and Google Lighthouse. These tools will scan the web page currently being viewed and outline issues, why the issue is present, where the issue is occurring, what the associated WCAG rule is and sometimes suggestions for remediation. Combine these automated tests with manual testing such as using the keyboard only, zoom the page, use OS available screen readers.
VPAT
When performing this initial auditing it would be a good idea to also fill out a VPAT – Voluntary Product Accessibility Template (version 2.5Rev 508 for government). This is for the most part taking any automated or manual testing and stating whether a WCAG guideline has been met or not. The documented results are considered an Accessibility Conformance Report – ARC. This document will help to outline and understand the current gaps in accessibility, what rules need to be met, is something that can be provided to whomever may be handling remediation and can be compared against when remediation is completed. It could also be posted on your current website as part of an accessibility statement. Even if a VPAT is not performed as part of the initial audit, it would be recommended to do so after conformance efforts have been made.
Prioritization
Whether running a site audit or a full VPAT, the goal is to have documented results which can then be prioritized. Prioritizing is ultimately an internal process decision, but there are a few things to take into consideration. Severity: what is the level of impact? Are your users being completely blocked from performing necessary actions or getting to information on your site? Are there some difficulties, but ultimately the task can be performed? Volume: is the issue prevalent in multiple instances across your site and implementing a simple fix could drastically reduce your accessibility issues? Traffic: are there certain pages that make up the majority of your website traffic and fixing that page specifically would be a good starting point? Content vs Design/Code: can the issue be fixed immediately by editing content?
Understanding and documenting accessibility requirements is not just about checking boxes—it’s about enabling inclusive access. Whether through WCAG principles, VPAT reports, or prioritizing key fixes, the focus should remain on aligning technical evaluations with user impact. This ensures that digital spaces are both compliant and truly usable by all.
Designing with Accessibility in Mind
There are numerous accessibility considerations to take into account when designing a holistic digital experience. A concept that will help to guide and drive an accessible experience is Universal Design. “Universal Design (UD) is the design and composition of an environment so that it can be accessed, understood and used to the greatest extent possible by all people regardless of their age, size, ability or disability.”⁵ In this case the environment means a website or mobile app and its content including videos and PDFs.
In terms of design itself, a few important factors are color contrast, presentation of hierarchical content – headings levels differentiated by size, consistency in placement and design of repetitive elements – think global navigation, and use of white space – visual content separation and button click state size. While there are no strict guidelines pertaining to fonts, generally sans-serif fonts are considered more accessible and using 16 pixels as a baseline size is an industry best practice. Incorporate testing as part of the design process.
Developing for Accessibility Compliance
Developing accessible digital experiences begins with following basic web development best practices. One of which is writing semantic markup – using elements that define the structure and meaning of content. These HTML structures provide visual uniformity, but are also machine readable which in turn help with screen readers and search engine optimization. ARIA – Accessible Rich Internet Applications – should be used when more information is needed to convey meaning, information and behaviors to screen reader technologies. Another vital practice (change this) is ensuring the site is keyboard friendly. A user should be able to use keyboard commands to easily navigate a site and clearly be shown indicators of where their keyboard focus is. Consider building in accessibility linting or testing as part of the CI/CD process.
While coders can ensure accessibility in markup, there is also the reliance on content editors to follow accessibility requirements. Clear language, appropriate reading level, image alternative text, and proper heading use are some of the big things to take into consideration when writing content.
Real-World Insights: Accessible by Design Webinar
I recently participated in the Accessible by Design webinar alongside our amazing client, The Ford Foundation, and our partners at WordPressVIP. Together, we shared practical strategies to help government web teams meet and exceed Section 508 standards.
This session focused on high-impact, low-effort improvements, aligning remediation strategies with evolving WCAG and Section 508 requirements, and fostering collaboration across content, design, and development teams.
Watch the Webinar
Accessibility Testing
The planning phase has outlined some automated and manual testing methods prior to making any accessibility updates. One further step is to plan for testing on a more iterative basis. Ideally testing is being performed during both the design and development phases, but as components of the website are for the most part finalized, they should go through more user testing and quality assurance testing. Also consider testing updates to content, PDFs and videos as a part of this process.
Deploying
This step can be taken in the more literal sense and is the actual deployment of code to either launch a new website/app or an update to an existing one. This step could also be considered the content entry phase as well – including adding accessible PDFs and videos to replace non-compliant ones.
Operating & Maintenance
Once a site or digital property is live, accessibility efforts must continue beyond deployment. Establish a regular schedule for testing and monitoring content—both manually and through automated tools—to ensure continued compliance, especially after updates or content changes.
Maintaining an updated Accessibility Statement on the website is also critical. This statement should communicate your organization’s commitment to accessibility, outline known limitations, provide a timeline for fixes, and offer a clear way for users to provide feedback or request accommodations. Including a contact form or accessibility request mechanism allows end-users to alert you to barriers they encounter in real-time.
Post-launch retrospectives or process reviews can also be highly beneficial. Reflect on what went well during implementation and what can be improved. Did your planning steps accurately capture the scope? Were timelines realistic? Do staff need more training? Did vendors deliver accessible solutions as promised?
Finally, monitor ongoing updates to WCAG and Section 508 standards to remain in alignment with evolving requirements. Accessibility is not a one-time event—it’s an ongoing commitment to digital inclusion.
Final Thoughts
Creating accessible digital experiences is a responsibility that spans design, development, content creation, and organizational culture. Accessibility is not only a legal requirement in many cases—it’s a moral imperative that ensures all users, regardless of ability, can access and engage with your content.
While tools and checklists are important, fostering a mindset of inclusion across teams and phases of work is what leads to long-term success. Accessibility should be approached not just as a task to complete, but as a value to uphold. Keep learning, adapting, and engaging with accessibility communities and experts.
Ultimately, accessibility benefits everyone—by creating cleaner, more usable, and future-ready digital experiences.
Accessibility Tools
This is by no means an exhaustive list, nor does it guarantee accessibility compliance. Ensure any tool is vetted prior to use.
| Design | Development | Content | QA |
| Figma | HTML Validator | Microsoft | WordPress Plugins: Equalize Digital Accessibility Checker WP Accessibility |
| InDesign | axe DevTools | Adobe Acrobat Pro | Drupal Modules: Editora11y |
| WebAIM Color Contrast Checker | Wave | Third-party Services: Siteimprove axe Monitor Level Access | |
| WebAIM Link Contrast Checker | Google Lighthouse | Trusted Tester Program |
Further Reading and Reference Links
- https://www.w3.org/WAI/standards-guidelines/wcag
- https://www.section508.gov
- https://designsystem.digital.gov
- https://www.itic.org/policy/accessibility/vpat
Footnotes
- https://www.section508.gov/develop/incorporating-accessibility-conformance/
- https://www.ada.gov/resources/web-rule-first-steps/#action-step-2-figure-out-when-you-need-to-fully-comply-with-the-rule
- https://accessible-eu-centre.ec.europa.eu/content-corner/news/eaa-comes-effect-june-2025-are-you-ready-2025-01-31_en
- https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1¤tsidebar=%23col_overview#top
- https://universaldesign.ie/about-universal-design



