DEV Community: IAAP Audit

WCAG 2.2 Success Criteria for Developers

IAAP Audit — Tue, 21 Jul 2026 05:39:46 +0000

WCAG success criteria become much less abstract when you read them as user-facing requirements.

They describe what your interface needs to support so people can use it with different abilities, devices, browsers, and assistive technologies.

Think in POUR

WCAG groups requirements under four principles:

Perceivable: users can access the information.
Operable: users can use the controls.
Understandable: users can understand the content and errors.
Robust: the interface works with assistive technology.

Most accessibility bugs fall cleanly into one of these areas.

Common developer-facing failures

You will often see criteria fail through implementation details such as:

button behavior recreated with a div.
Missing form labels.
Error messages not connected to fields.
Low contrast text.
Focus hidden by sticky headers.
Modals that do not manage focus.
Custom widgets with wrong roles or states.
Status messages that screen readers never receive.

The fix is usually more practical than the criterion name suggests.

What WCAG 2.2 adds

WCAG 2.2 adds checks that matter in modern apps:

Focus Not Obscured.
Dragging Movements.
Target Size Minimum.
Consistent Help.
Redundant Entry.
Accessible Authentication.

If you own a design system, review these at the component level.

How to write audit issues well

A good WCAG issue should be reproducible.

Include:

URL or screen.
Component.
Steps to reproduce.
Expected behavior.
Actual behavior.
User impact.
Criterion and level.
Suggested fix.
Retest status.

This turns WCAG from a label into an engineering task.

Do not rely only on automation

Automated tools help, but they cannot fully test keyboard flow, screen reader meaning, focus order, authentication experience, or real task completion.

Use tools for coverage. Use manual testing for confidence.

Conclusion

WCAG 2.2 success criteria are not separate from product quality. They are product requirements for accessible interaction.

Learn the intent, map issues clearly, and retest the user journey after fixes.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/wcag-2-2-success-criteria-plain-english

How to Pick a WCAG Audit Partner

IAAP Audit — Mon, 20 Jul 2026 06:28:44 +0000

If you are a developer or QA lead, a weak accessibility audit can create more work than it solves.

The issue is not only whether problems are found. The issue is whether the report gives your team enough context to fix them.

Avoid scan-only audits

Automated tools are useful, but a scan export is not the same as a WCAG audit.

Manual review is needed for:

Keyboard navigation.
Focus order.
Screen reader output.
Form errors.
Dialogs and menus.
Dynamic updates.
Custom widgets.
Documents and PDFs.

If these are not included, expect gaps.

Check the issue format

A useful audit issue should look like a good defect ticket.

It should include:

URL or screen.
Component.
Steps to reproduce.
Expected behavior.
Actual behavior.
User impact.
WCAG criterion.
Severity.
Fix direction.
Retest status.

If the report says only "fails WCAG", it is not enough.

Ask how samples are selected

Not every page needs identical depth, but the sample should make sense.

A strong sample includes:

Main templates.
High-risk journeys.
Forms.
Authenticated screens.
Reusable components.
Dynamic states.
Documents.
Mobile layouts.

Sampling should be explained, not guessed.

Look for remediation support

Good audit partners help teams interpret findings.

That does not mean they rewrite your code. It means they can explain the expected accessible behavior, identify likely ownership, and clarify patterns such as focus management, ARIA misuse, document structure, or form recovery.

Retesting matters

Accessibility fixes need verification. A code change is not the same as closure.

Retesting should confirm whether the barrier is fixed and whether the user can complete the task.

Conclusion

Pick an audit partner who understands delivery, not only compliance language.

The best audits give engineering teams reproducible issues, practical guidance, and a clear retest path.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/how-to-choose-accessibility-audit-partner

Banking Accessibility Audit Checklist

IAAP Audit — Fri, 17 Jul 2026 05:18:05 +0000

Banking and fintech apps have accessibility risks that ordinary websites often do not.

Users are completing high-impact actions: identity verification, payments, card controls, account updates, statements, complaints, and support escalation.

1. Audit real workflows

Do not test only static screens.

Include:

Login.
OTP.
Password reset.
KYC.
Uploads.
Beneficiary management.
Payments.
Transaction history.
Statements.
Support requests.

Accessibility failures often appear in dynamic states.

2. Test keyboard and focus behavior

Check:

Tab order.
Focus visibility.
Modal focus.
Menu behavior.
Error recovery.
Payment confirmation.
Session timeout.

Users should be able to complete the journey without a mouse.

3. Test screen reader output

Review names, roles, states, values, headings, landmarks, form labels, error messages, and status updates.

Banking controls often have icon-only buttons, masked values, expandable sections, warning banners, and transaction statuses. These need clear assistive technology output.

4. Make security controls accessible

Security does not excuse inaccessible behavior.

Review:

OTP fields.
CAPTCHA alternatives.
Device verification.
Biometric fallback.
Timeout warnings.
Fraud alerts.
Recovery flows.

The user needs an accessible path to continue or recover.

5. Do not ignore documents

Statements, terms, fee tables, receipts, repayment schedules, and notices need document accessibility review.

A PDF that looks correct can still fail for screen reader users if tags, headings, reading order, tables, links, or language are missing.

6. Document findings like production defects

A good audit issue includes:

Screen or workflow.
Steps to reproduce.
Expected behavior.
Actual behavior.
User impact.
WCAG mapping.
Suggested fix.
Retest result.

That format makes remediation realistic.

Conclusion

Accessibility in banking is about task completion, not just page appearance.

Test access, identity, payments, records, support, and documents with real states and evidence.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/rbi-digital-accessibility-audit-checklist-banks-fintech

Screen Reader Testing Checklist for WCAG

IAAP Audit — Thu, 16 Jul 2026 04:50:52 +0000

If you build web apps, screen reader testing should not happen only at the end of a project.

Many screen reader issues come from ordinary implementation choices: missing labels, incorrect roles, bad focus movement, hidden content, unannounced validation, and overused ARIA.

1. Start with semantic HTML

Before adding ARIA, check whether native HTML can solve the problem.

Review:

Headings.
Buttons.
Links.
Lists.
Tables.
Forms.
Landmarks.
Dialog structure.

Native controls usually provide better baseline semantics than custom div-based controls.

2. Check names, roles, states, and values

For every interactive control, ask:

What is its accessible name?
What role is exposed?
Is its current state announced?
Does the value update correctly?
Does the visible label match the accessible label?

This matters for buttons, toggles, tabs, comboboxes, sliders, menus, accordions, and custom widgets.

3. Test focus movement

Screen reader testing often depends on keyboard flow.

Check:

Focus order.
Dialog entry and exit.
Route changes.
Error recovery.
Dynamic content.
Hidden content.
Focus restoration after actions.

If focus moves to the wrong place, the user may not understand what changed.

4. Test forms with invalid data

Forms should be tested with real states, not only the happy path.

Check labels, instructions, required fields, input purpose, validation errors, field relationships, and confirmation messages.

Errors should be understandable and connected to the relevant fields.

5. Test announcements and live regions

Dynamic updates need careful handling.

Do not announce everything. Announce what helps the user continue the task.

Common examples:

Search results changed.
Item added to cart.
File upload completed.
Save succeeded.
Validation failed.
Session expired.

6. Write findings like defects

A useful finding includes:

Assistive technology and browser used.
Steps to reproduce.
Expected announcement.
Actual announcement.
Affected component.
User impact.
WCAG mapping.
Fix recommendation.
Retest result.

This helps developers fix the behavior, not only the markup.

Conclusion

Screen reader testing is not mysterious. It is structured interaction testing with assistive technology.

Use semantic HTML, verify names and roles, test forms and dynamic updates, and document evidence clearly.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/screen-reader-testing-checklist-accessibility-audits

Keyboard Accessibility Testing Checklist

IAAP Audit — Wed, 15 Jul 2026 05:55:32 +0000

If you build web apps, keyboard testing should be part of your normal QA workflow.

Many accessibility blockers are easy to find with a keyboard, but they are often missed because teams only test with a mouse or trackpad.

1. Navigate the full workflow

Do not only tab across one page.

Test the full journey:

Login.
Search.
Filtering.
Form entry.
Validation.
Upload.
Payment.
Dashboard actions.
Account settings.
Downloads.

If a user cannot complete the path without a mouse, the workflow is not keyboard accessible.

2. Check focus visibility

Every interactive element needs a visible focus state.

Watch for:

Removed outlines.
Low-contrast focus rings.
Focus hidden under sticky UI.
Focus shown on a wrapper instead of the actual control.
Focus lost after route changes or dynamic updates.

Use screenshots or screen recordings when reporting visual focus bugs.

3. Check focus order

Focus order should preserve meaning and operability.

Problems often appear when CSS changes layout, cards include nested links, modals open, sidebars collapse, or hidden content remains focusable.

Common fixes include:

Using native HTML controls.
Removing hidden elements from the tab order.
Returning focus after dialogs close.
Avoiding positive tabindex values.
Managing focus after dynamic updates.

4. Look for keyboard traps

Keyboard traps are serious.

Test:

Modals.
Carousels.
Maps.
Video players.
Embedded widgets.
Chat components.
Custom menus.

If focus enters but cannot leave, the journey is blocked.

5. Test custom widgets with expected keys

Custom widgets need intentional keyboard support.

Check menus, tabs, accordions, comboboxes, date pickers, sliders, grids, and drag-and-drop tools.

Ask:

Can I reach it?
Can I operate it?
Can I understand state changes?
Can I leave it?
Does it work with assistive technology semantics?

6. Write findings developers can close

A good keyboard accessibility bug includes:

Page or component.
Steps to reproduce.
Expected behavior.
Actual behavior.
User impact.
WCAG mapping.
Recommended fix.
Retest result.

That level of detail prevents vague tickets and speeds remediation.

Conclusion

Keyboard accessibility is practical. You can test it today with no special tooling.

Run through real journeys, check focus, find traps, fix custom widgets, and retest before calling the issue closed.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/keyboard-accessibility-checklist-websites-web-apps

Manual vs Automated Accessibility Testing

IAAP Audit — Tue, 14 Jul 2026 05:44:51 +0000

Automated accessibility checks are useful. They are also incomplete.

If you are a developer or QA engineer, the right model is not tool versus human. The right model is tool plus human, with clear evidence and retesting.

Use automation where it is strong

Automated checks are good for fast feedback.

Use them for:

CI checks.
Pull request feedback.
Component library review.
Repeated template checks.
Regression monitoring.
Quick pre-audit cleanup.

They can catch many obvious problems before an auditor ever sees the product.

Do not use scan output as the final answer

An automated pass does not prove that a user can complete a workflow.

A tool may not know whether:

A label is helpful.
Focus movement is logical.
A screen reader announcement is understandable.
A modal behaves correctly.
A user can recover from an error.
A document has meaningful reading order.
A checkout or registration flow is actually usable.

Those failures usually need manual testing.

Manual checks developers should expect

A serious accessibility audit will test behavior, not only markup.

Expect review of:

Keyboard-only navigation.
Focus order and visible focus.
Screen reader name, role, state, and value.
Form validation and error messages.
Dialogs, menus, tabs, accordions, and custom widgets.
Media alternatives.
PDFs and document downloads.
Authenticated flows and dynamic states.

These checks often produce better engineering tickets because they explain the barrier, not only the rule.

Write audit findings like defects

Accessibility findings should be reproducible.

A strong ticket includes:

Affected page or component.
Steps to reproduce.
Expected behavior.
Actual behavior.
User impact.
WCAG mapping.
Severity.
Recommended fix.
Retest result.

If the team cannot reproduce it, the finding is not ready.

Build a practical workflow

For product teams, a balanced workflow is straightforward:

Run automated tools early.
Fix low-effort repeat failures.
Manually test high-risk journeys.
Include assistive technology checks.
Add evidence to the report.
Retest before closure.

This avoids the common problem where accessibility work becomes a late compliance scramble.

Conclusion

Automation is a useful filter. Manual testing is where accessibility becomes real.

If your audit needs to support WCAG evidence, remediation, and retesting, you need both.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/manual-vs-automated-accessibility-testing

GIGW 3.0 Accessibility Testing Checklist

IAAP Audit — Mon, 13 Jul 2026 04:08:42 +0000

If you are building or maintaining an Indian government website, portal, or app, accessibility cannot be reduced to a Lighthouse score.

GIGW 3.0 accessibility testing needs a mix of automated checks, manual review, assistive technology checks, document review, and evidence that remediation teams can act on.

1. Build the scope list first

Before testing, list the real assets.

Public pages.
Login and authenticated areas.
Search and filter pages.
Forms and validation states.
Upload, download, and payment flows.
Mobile app screens.
PDFs and scanned documents.
Videos and audio.
Grievance and contact workflows.

This prevents the common problem where only the public homepage is tested.

2. Use automated checks as the first pass

Automated tools are useful for common failures:

Missing accessible names.
Some colour contrast issues.
Duplicate IDs.
Obvious ARIA problems.
Missing document language.
Empty headings or buttons.

But they are not enough. They cannot prove task completion.

3. Manually test keyboard behavior

Keyboard testing should include:

Tab sequence.
Shift+Tab sequence.
Enter and Space activation.
Escape behavior in dialogs.
Focus trapping where appropriate.
No accidental keyboard traps.
Visible focus on every interactive element.

Custom controls need extra attention because native behavior is often lost when teams recreate UI components.

4. Test forms with real errors

Forms need more than labels.

Check:

Required field indication.
Label association.
Help text association.
Error message association.
Summary and inline error behavior.
State changes after submission.
Timeout and session handling.
OTP, CAPTCHA, and verification alternatives.

Use realistic data so validation states appear.

5. Review documents separately

PDF and document accessibility needs its own pass.

Check tags, reading order, headings, table structure, link text, alt text, document language, title metadata, and form fields. If a file is scanned, OCR alone is not enough. The document still needs semantic structure.

6. Test mobile and app behavior

For responsive pages and apps, test with platform accessibility settings.

Screen reader order.
Text scaling.
Display scaling.
Orientation changes.
Touch target spacing.
Gesture alternatives.
Control name, role, state, and value.

Government app flows often fail here because desktop assumptions do not transfer cleanly to mobile.

7. Write findings developers can close

A useful issue includes:

Location.
Steps to reproduce.
Expected behavior.
Actual behavior.
User impact.
WCAG or GIGW mapping.
Severity.
Fix guidance.
Retest note.

If a developer cannot reproduce the issue, the report is not ready.

Conclusion

GIGW 3.0 accessibility testing should be practical, not ceremonial.

Start with scope, combine automated and manual testing, include documents and apps, write actionable findings, and retest fixes with evidence.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/gigw-3-0-accessibility-checklist-websites-apps

IS 17802 vs WCAG: Audit Scope Guide

IAAP Audit — Fri, 10 Jul 2026 05:58:47 +0000

If you are a developer or QA engineer working on an accessibility audit in India, the standard named in the audit scope changes the work you will receive.

A vague issue like accessibility problem is hard to fix. A standards-mapped issue with steps, expected behavior, user impact, and retest criteria is useful.

That is where WCAG and IS 17802 need to be understood correctly.

WCAG is the implementation-friendly baseline

WCAG is usually where web defects become actionable. It gives a way to map a problem to a specific success criterion.

Examples:

A button has no accessible name.
Focus disappears behind a sticky header.
A modal traps keyboard users.
A form error is visual only.
A PDF link has no meaningful text.
A touch target is too small.

These are not abstract compliance notes. They are implementation defects that affect real users.

IS 17802 is not just another label for WCAG

IS 17802 is the Indian ICT accessibility standard. If the buyer asks for it, the report may need to do more than map common web defects to WCAG.

Depending on scope, it may involve broader ICT products and services, documentation, documents, support content, apps, procurement evidence, and conformance reporting expectations.

For engineering teams, the lesson is simple: ask what the report must map to before remediation starts.

What useful audit tickets look like

A strong accessibility issue should include:

What failed.
Where it failed.
How to reproduce it.
Who is affected.
Which standard is mapped.
What the expected behavior is.
What remediation approach is recommended.
How the fix will be retested.

Without those details, teams waste time debating the issue instead of fixing it.

Why manual testing still matters

Automated tools can flag markup and some programmatic failures. They cannot reliably validate the full user journey.

Manual review is needed for:

Keyboard-only completion.
Logical focus order.
Screen reader context.
Form recovery.
Modal behavior.
Meaningful alt text.
Document structure and reading order.
Real task completion.

That is why an accessibility audit should combine scanning, expert review, assistive technology checks, and retesting.

How to prepare the codebase

Before audit handoff, teams can reduce noise by checking basics:

Use semantic HTML before custom ARIA.
Make every interactive control keyboard accessible.
Ensure visible focus is not hidden.
Connect labels, descriptions, and errors to form fields.
Test key journeys without a mouse.
Check PDFs and downloadable documents separately.
Keep component behavior consistent across pages.

Conclusion

For developers, WCAG usually explains the web defect. IS 17802 may explain why the buyer needs India-specific ICT accessibility evidence.

Treat both as scope inputs. The better the audit mapping, the faster the remediation cycle becomes.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/is-17802-vs-wcag-indian-organizations-guide

WCAG 2.1 vs 2.2: What Changes for Audits

IAAP Audit — Thu, 09 Jul 2026 05:11:28 +0000

When a team says "we need a WCAG audit", the next question should be:

Which version, which level, and which scope?

WCAG levels are cumulative. Level AA includes Level A and Level AA requirements. Level AAA includes A, AA, and AAA requirements.

That affects what gets tested and what appears in the report.

Why this matters for implementation

If the target level is unclear, engineering and QA teams can end up with ambiguous findings.

A report should say whether a defect maps to Level A, Level AA, or Level AAA. It should also explain whether AAA checks were part of formal scope or included only as advisory recommendations.

Level A: baseline access

Level A issues are often blockers.

Think about:

Keyboard access
Missing labels
Missing text alternatives
Broken structure
Blocking interaction patterns
Assistive technology incompatibility

These are not small polish issues. They can prevent task completion.

Level AA: common audit target

AA is usually the right target for production audit work.

It includes Level A and adds important requirements around contrast, focus, navigation, input assistance, resizing, labels, and interaction behavior.

For developers and QA teams, AA findings usually become practical remediation tickets with clear expected behavior and retest conditions.

Level AAA: selective deeper coverage

AAA is the highest conformance level.

It can be valuable, but it is not always a realistic whole-product requirement.

Use selected AAA checks when the content or journey justifies deeper accessibility support. Examples may include education, healthcare, public information, financial disclosure, or critical service journeys.

Scope checklist

Before the audit starts, confirm:

WCAG version
Target level
Pages and templates
Authenticated journeys
Forms and errors
PDFs and documents
Component states
Keyboard and assistive technology coverage
Retest expectations

Final note

The target level should be explicit. "WCAG compliant" is too vague for implementation work.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/wcag-a-vs-aa-vs-aaa-audit-buyers-guide

WCAG A, AA, and AAA: What Teams Should Scope

IAAP Audit — Wed, 08 Jul 2026 05:19:17 +0000

When a team says "we need a WCAG audit", the next question should be:

Which version, which level, and which scope?

WCAG levels are cumulative. Level AA includes Level A and Level AA requirements. Level AAA includes A, AA, and AAA requirements.

That affects what gets tested and what appears in the report.

Why this matters for implementation

If the target level is unclear, engineering and QA teams can end up with ambiguous findings.

A report should say whether a defect maps to Level A, Level AA, or Level AAA. It should also explain whether AAA checks were part of formal scope or included only as advisory recommendations.

Level A: baseline access

Level A issues are often blockers.

Think about:

Keyboard access
Missing labels
Missing text alternatives
Broken structure
Blocking interaction patterns
Assistive technology incompatibility

These are not small polish issues. They can prevent task completion.

Level AA: common audit target

AA is usually the right target for production audit work.

It includes Level A and adds important requirements around contrast, focus, navigation, input assistance, resizing, labels, and interaction behavior.

For developers and QA teams, AA findings usually become practical remediation tickets with clear expected behavior and retest conditions.

Level AAA: selective deeper coverage

AAA is the highest conformance level.

It can be valuable, but it is not always a realistic whole-product requirement.

Scope checklist

Before the audit starts, confirm:

WCAG version
Target level
Pages and templates
Authenticated journeys
Forms and errors
PDFs and documents
Component states
Keyboard and assistive technology coverage
Retest expectations

Final note

The target level should be explicit. "WCAG compliant" is too vague for implementation work.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/wcag-a-vs-aa-vs-aaa-audit-buyers-guide

SEBI Table C4: Remediation Evidence Checklist

IAAP Audit — Tue, 07 Jul 2026 05:16:52 +0000

For engineering and QA teams, C4 should be treated as a closure-evidence workflow.

The table records final or current remediation status, but the useful work is the evidence that explains what changed after the initial audit.

Start with issue traceability

Every remediated item should point back to the original finding.

Keep:

Original issue ID
Affected page or component
User impact
Expected accessible behavior
Standard reference
Severity

This makes later verification easier.

Record the remediation action

For each important issue, capture what changed.

Examples:

Added programmatic label
Fixed focus order
Added visible focus indicator
Corrected ARIA relationship
Reworked modal focus management
Updated PDF tags or reading order
Added captions or transcript
Fixed contrast or target size

Short, specific notes are better than vague closure language.

Retest with the right condition

Retest notes should describe how the fix was checked.

Depending on the issue, that may include:

Keyboard-only path
Screen reader behavior
Mobile assistive technology behavior
Browser and device context
PDF version
Form error handling
Component state

The goal is to prove the accessible behavior, not only that code changed.

Track unresolved risks

Not every issue may be closed immediately.

For open or deferred items, capture:

Why it remains open
Current user impact
Dependency or blocker
Planned remediation path
Expected timeline
Interim risk control if any

This keeps the C4 status honest.

Final checklist

Before C4 preparation, ask:

Can each status be traced to a C3 finding?
Is remediation evidence available?
Are retest notes clear?
Are partial fixes identified?
Are open issues explained?
Does the status wording match the tested scope?

If yes, the C4 package is much easier to defend.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/sebi-table-c4-remediation-final-status-guide

SEBI Table C3: Submission Table, Not Report

IAAP Audit — Mon, 06 Jul 2026 06:25:00 +0000

For teams preparing SEBI digital accessibility submissions, one detail matters:

Table C3 is not the full audit report.

It is the submission table. The initial accessibility audit report should be attached as a consolidated PDF.

What developers and QA teams should know

The table asks for high-level details:

Auditor or firm
Audit completion date
Platforms covered
Terms of reference
Scope
Key findings
Observations
Action plan
Remediation timelines

The attached report should contain the actionable implementation detail.

What should be in the attached report

The report should support remediation.

Useful findings usually include:

Affected URL, screen, component, journey, or document
Steps or context to reproduce
Observed behavior
Expected accessible behavior
User impact
Severity
WCAG or other standards mapping
Evidence
Recommended fix direction

If the report does not provide this, developers may need to rediscover the issue before fixing it.

Scope and exclusions

Scope should be explicit.

If a portal, app, PDF, document library, login journey, form, or third-party flow was not tested, the report should say that. This keeps the C3 submission honest and prevents false confidence.

Preparing for later closure

C3 creates the initial baseline.

If the findings are traceable and the remediation timelines are practical, the later final-status stage is easier. Teams can show what changed, what remains open, and what evidence supports closure.

Final checklist

Before treating a C3 package as ready, check:

Is the table filled accurately?
Is the consolidated report attached?
Is scope clear?
Are findings reproducible?
Is evidence included?
Are standards mapped?
Are remediation timelines realistic?

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/sebi-table-c3-accessibility-audit-submission-guide