FAQ

WCAG stands for Web Content Accessibility Guidelines. It is the internationally recognized technical standard for digital accessibility developed by the W3C (World Wide Web Consortium). It is broken down into three levels of conformance: Level A (minimum), Level AA (industry standard and legal baseline), and Level AAA (highest design standard).

A VPAT is a standardized document template created by the Information Technology Industry Council (ITI). It is used by vendors to disclose exactly how well an Information and Communication Technology (ICT) product conforms to accessibility standards like Section 508 and WCAG.

An ACR is the final, completed document generated after a professional accessibility audit has been mapped onto a empty VPAT template. It explicitly states a product's compliance status and is used by procurement officers during vendor vetting.

ARIA (often written as WAI-ARIA) is a set of specialized attributes added to HTML markup that provides crucial semantic meaning, names, roles, and real-time state updates to assistive technologies (like screen readers) when native HTML elements fall short.

ICT is an umbrella term that covers any communication device or application—including software, hardware, websites, mobile applications, and digital documents—subject to regulatory standards like Section 508.

A full manual audit covers keyboard navigation, screen reader compatibility, color contrast, focus management, form labeling, error handling, and more, tested against WCAG 2.1 and 2.2 criteria. I test with real assistive technology including NVDA,Orca , and TalkBack, not just automated scanners. You receive a detailed issue log and a plain-language executive summary your whole team can act on.

Automated scanners catch roughly 30 to 40% of accessibility issues, things like missing alt text or low color contrast that are easy to detect programmatically. The other 60 to 70% only surface when a real person uses your product with assistive technology. A manual audit catches keyboard traps, confusing screen reader announcements, and interaction patterns that no scanner can evaluate.

Yes, always. I test with NVDA on Windows, Orca on debian 13, and TalkBack on Android. I also test keyboard-only navigation across browsers. Automated tools are a starting point, not a finish line.

NVDA (Windows), Orca(linux) and TalkBack (Android). These cover the assistive technologies most commonly used by screen reader users in the real world.

It depends on the size and complexity of what's being audited. A small site under 20 pages typically takes one to two weeks. A mid-size app or site can take three to four weeks. Enterprise-scale products are scoped individually. I'll give you a clear timeline before we begin.

You receive a WCAG-mapped issue log documenting every finding with its severity, the relevant success criterion, steps to reproduce, and a clear remediation recommendation. You also get a plain-language executive summary suitable for leadership or board review, not just a spreadsheet of errors.

WCAG stands for Web Content Accessibility Guidelines, the internationally recognized technical standard for digital accessibility published by the W3C. WCAG 2.1 is currently the version referenced by most laws and regulations including ADA Title II and Section 508. WCAG 2.2 was published in 2023 and adds several important criteria, particularly around mobile and cognitive accessibility. I audit against both.

Level A covers the most critical barriers, issues that make content completely unusable for some users. Level AA is the standard required by most laws and regulations and represents a meaningful level of accessibility for most users. Level AAA is the highest level and not required by law, but represents best practice. Most organizations should target Level AA as a baseline.

WCAG conformance is the technical standard adopted by many countres as an international standard. In the United States it has been adopted by the DOJ for ADA Title II and Section 508 standards, so meeting it is the clearest path to compliance. That said, I'm not a lawyer and nothing I provide constitutes legal advice. What I can tell you is that a documented audit showing good-faith effort toward WCAG 2. AA is the strongest position you can be in if a complaint is filed.

Section 508 applies to federal agencies and organizations that receive federal funding, it requires accessibility for ICT procured or developed with federal funds. ADA Title II applies to state and local government entities and is enforced by the DOJ. Both now point to WCAG 2.1 AA as the technical standard, but they cover different entities and have different enforcement mechanisms.

Title II of the Americans with Disabilities Act prohibits discrimination by state and local government entities. A 2024 DOJ final rule now explicitly requires those entities to meet WCAG 2.1 Level AA for their websites, mobile apps, and digital content. If your organization is a city, county, state agency, public school, public university, transit authority, court, or public library, it applies to you.

Large entities serving populations of 50,000 or more had a compliance deadline of April 24, 2026, which has already passed. Smaller entities serving populations under 50,000 have until April 24, 2027. If your large organization is not yet compliant, you are already at legal risk and should prioritize remediation immediately.

Start now. Document your current state with a professional audit, begin remediating the highest-severity issues first, and establish an ongoing accessibility process. A documented good-faith effort is important if a complaint is filed. I can help you prioritize and work through remediation systematically.

Generally yes, if your organization uses third-party tools or embeds third-party content as part of your public-facing services, those are considered part of your digital offering under Title II. You should either ensure vendors provide accessible products or have a plan for accessible alternatives.

Government agencies, nonprofits, and businesses regularly publish forms, reports, notices, and policies as PDFs. If those documents aren't properly tagged and structured, screen reader users cannot read them at all. Inaccessible PDFs are one of the most common accessibility failures, and one of the most cited in complaints.

Not necessarily. Exporting from Word to PDF preserves some structure but often loses reading order, skips alt text on images, and fails to properly tag tables and form fields. Every PDF needs to be reviewed and remediated individually to confirm it meets PDF/UA and WCAG standards.

Tag structure and reading order, alt text for images and figures, accessible tables, form field labeling, document language, title metadata, color contrast, and navigability for screen reader and keyboard users. I check against PDF/UA, WCAG 2.1, and Section 508 where applicable.

A VPAT (Voluntary Product Accessibility Template) is a standardized document that describes how a product conforms to accessibility standards. A completed VPAT becomes an Accessibility Conformance Report (ACR). You need one if you sell software, SaaS, or digital products to government agencies, large enterprises, or any organization with an accessibility procurement requirement.

Federal agencies (required by Section 508), state and local government procurement offices (increasingly required under Title II), large enterprises with formal vendor vetting processes, universities, and healthcare organizations. If you're selling to any of these markets, having a current VPAT is essential.

A VPAT written without an underlying audit is essentially guesswork, and submitting an inaccurate VPAT to a government agency can create more legal exposure than having no VPAT at all. I write VPATs based on actual audit findings, which means the document reflects the real conformance state of your product.

I offer accessibility training for developers, designers, content teams, and QA teams, covering WCAG standards, screen reader usage, accessible code patterns, inclusive design principles, and ADA Title II compliance. I also offer training for social workers and nonprofit staff working with disabled foster youth.

I design training for the actual audience. Technical training for developers and QA teams uses code examples and testing walkthroughs, while design training focuses on color contrast, typography, and interaction patterns. Non-technical staff get plain-language guidance they can apply immediately without needing to understand the underlying standards.

Yes, every training engagement is shaped around your team's actual work, your tech stack, your product, and your industry context. A training for a government agency will look different from one for a SaaS startup. I don't deliver generic slide decks.

Yes. I cover semantic HTML, ARIA usage and misuse, focus management, keyboard interaction patterns, accessible form design, and how to test with real screen readers during development. Developers leave with practical patterns they can apply immediately.

Yes. I cover color contrast requirements, accessible typography, focus indicator design, interaction states, error messaging, and how to communicate accessibility requirements to developers through design specs and annotations.

Yes. Content training covers plain language, meaningful link text, alt text writing, accessible heading structure, caption quality, and how content decisions affect screen reader users. Content teams have more impact on accessibility than most people realize.

Yes. QA training covers how to use keyboard-only testing, how to run a screen reader test, what to look for in automated scan results, how to write accessibility bug reports, and how to include accessibility in your standard QA process.

Yes. I can train government agency staff on what Title II requires, what WCAG 2.1 AA means in practice, how to evaluate their existing digital properties, and how to build accessibility into their procurement and content publishing processes going forward.

Yes. Every training engagement includes materials your team can reference after the session, such as checklists, reference guides, and documented examples specific to your product and workflow.

Both. Virtual training works well for most teams and removes travel constraints. In-person is available for organizations that prefer it or for larger workshop formats where hands-on collaboration adds value.

I speak on digital accessibility and inclusive design, the real-world impact of inaccessible technology on disabled people, ADA Title II and the evolving legal landscape, video game accessibility, and the experience of disabled foster youth, including systemic advocacy and policy.

Tech conferences, UX and design events, government and policy convenings, nonprofit advocacy events, university programs, and organizational all-hands or team events. If the audience cares about building better products or supporting marginalized communities, I have something to say.

Yes. I don't deliver the same talk everywhere. I'll work with you to understand your audience, their level of familiarity with accessibility, and what you want them to walk away with, then shape the content accordingly.

Both. Virtual keynotes and panels are available. In-person speaking is available with appropriate travel arrangements.

Yes. Beyond keynote-style talks, I offer organizational workshops and fireside chat formats that allow for more interaction and deeper engagement with the material.

Video game accessibility refers to the features and design decisions that determine whether gamers with disabilities can actually play a game. This includes font size, color contrast, subtitle and caption quality, control remapping, difficulty options, cognitive load, and motor accessibility. When these are done poorly, disabled gamers spend $60 to $80 on a title they cannot play.

UI design and readability, color contrast, font size and legibility, subtitle and caption quality, control remapping options, audio design, difficulty and assist options, cognitive accessibility, and overall navigation. Reviews are designed to help disabled gamers make informed purchase decisions.

Yes. Pre-launch developer audits are available and cover the same areas as my consumer reviews but with remediation guidance included. Catching accessibility issues before launch is significantly less costly than patching them after release.

Website audits are evaluated against WCAG and established web standards. Game accessibility is evaluated against community-developed guidelines like the Game Accessibility Guidelines (GAG) and IGDA recommendations, as well as direct experience as a disabled gamer. The testing methodology, tools, and criteria are different, but the goal is the same: real usability for real people.

My video game accessibility reviews are available on the Video Game Accessibility Reviews page of this site. Each review includes an interactive transcript.

I am a former foster youth and a disabled person. I entered the foster care system and navigated it as a severely disabled young person, which gave me direct, lived understanding of the barriers disabled foster youth face. That experience drives my advocacy work today.

Yes. I have trained social workers on how to more effectively support disabled youth in their care, covering communication approaches, understanding disability experience, and connecting youth to appropriate resources and planning for life beyond care.

Awareness of the specific challenges disabled foster youth face, how disability intersects with the foster care system, effective communication and support strategies for practitioners, tools and resources available to support disabled youth, and transitional planning for youth aging out of care.

Yes. I speak at foster youth events, nonprofit convenings, and policy discussions, sharing my personal story and advocating for systemic change that better supports disabled youth in care and as they transition out of it.

Yes. I work with nonprofits, advocacy organizations, and government agencies focused on foster youth, through speaking, training, and consultation on how to better serve disabled youth in their programs.

I advocate for legislation that improves outcomes for disabled foster youth, including transition support, access to disability services during and after care, awareness-building among practitioners, and systemic accountability for how disabled youth are treated within the foster care system.

If you have an existing product and want to know where you stand, you need an audit. If you're early in development and want to build accessibly from the start, a consultation or training engagement is the right fit. If you're not sure, reach out and we'll figure it out together.

Yes. I work with organizations of all sizes, from individual product teams to large government agencies. I understand that nonprofits and small organizations often have limited budgets, and I'm happy to discuss what's feasible for your situation.

The audit deliverable includes clear remediation guidance for every finding. I can also provide ongoing advisory support as your team implements fixes, review remediated code or designs, and conduct a follow-up evaluation to confirm issues have been resolved.

I was born severely disabled and was not expected to walk, think cognitively, talk or live a "normal life". As a result, I have used both analog and digital assistive technologies my entire life. I have also been doing accessibility work since 2013 long before digital accessibility standards were developed. What you are hiring is someone who has over 30 years of lived experience in being disabled along with the skillset to train your team.

Pricing depends on the scope of the engagement, the size of your site or app, the number of documents, the format and length of training, and other factors. I don't publish fixed rates because I don't believe in one-size-fits-all pricing. Reach out through the contact form and I'll give you a clear picture of what your project would involve.