ASSESSMENT METHODOLOGY
How the A11yGo Accessibility Assessment Works
A transparent look at exactly what the automated assessment checks, how the website accessibility score is calculated, and — just as importantly — what it does not claim to measure.
The core principle: separate measurements
The assessment deliberately keeps four things separate: website accessibility (what was found), accessibility standards (WCAG / IS 17802 references), accessibility technology (any toolbar, widget or native controls detected on the page), and A11yGo enhancements (what A11yGo adds, measured independently). A website score is never changed by whether a toolbar is installed, and the score is never presented as a compliance score.
01 · WHAT IT MEASURES
Eight separate measurements
Each measurement is produced independently and reported separately.
Website Accessibility Score
Automated score (0–100) based only on detected characteristics.
Accessibility Issues
Normalized findings with severity, occurrences and impact.
Standards Mapping
WCAG 2.1 / 2.2 / WAI-ARIA references, only where verified.
Solution Detection
Vendor-neutral detection of any accessibility tool or controls.
Features Detected
Which accessibility features appear to be available.
A11yGo Coverage
A separate metric measuring A11yGo feature availability only.
Manual Review
Items automation cannot judge — clearly marked for human testing.
Recommended Actions
Prioritized remediation and enhancement guidance.
02 · PARAMETERS CHECKED
The 17 check categories
What the automated scanner examines on the page you submit.
Document & Page Structure
Missing or empty page title, document language, invalid language code, missing <main> / navigation landmarks, heading structure, skipped heading levels, duplicate IDs.
Images & Non-text Content
Images without alt text, empty alt, extremely long alt, SVG without an accessible name. Semantic correctness of alt text is flagged for manual verification.
Links
Empty links, image-only links, ambiguous text ("click here", "read more"), placeholder href="#" patterns.
Buttons & Interactive Controls
Buttons without accessible names, icon-only buttons, div/span used as interactive controls, missing roles/states.
Forms
Inputs, selects and textareas without labels, placeholder used as the only label — especially relevant for banks and NBFCs. Labels, required fields and error association.
Color & Contrast
Possible low-contrast inline styles, information conveyed only by color. Exact ratios are only claimed when they can be computed reliably.
Keyboard Accessibility
Positive tabindex, focus outline removal. Full keyboard operability is a manual review item.
Focus
Visible focus indicators, suspicious CSS that disables focus. Focus behavior inside dialogs is manual review.
WAI-ARIA Analysis
Invalid ARIA roles, broken aria-labelledby/describedby/controls references, redundant or inappropriate ARIA. WAI-ARIA is a technology, not a compliance framework.
Navigation
Skip links, navigation landmarks, consistent navigation, accessible names for navigation.
Text, Zoom & Reflow
user-scalable=no, restrictive maximum-scale, viewport restrictions that prevent zooming.
Motion & Animation
CSS animations, transitions, moving/flashing elements, prefers-reduced-motion support. Animation is flagged for review, not automatically as a failure.
Audio & Video
Video/audio elements, autoplay, captions <track>. Caption quality is manual verification.
Tables
Missing header cells, missing captions, complex tables — particularly relevant for financial institutions.
iFrames & Third-party Content
iFrames (payments, maps, chat, social), missing titles. Third-party content is reported, not automatically classed as inaccessible.
CAPTCHA
reCAPTCHA, hCaptcha and other implementations. Reported as "review recommended", not a failure.
PDFs & Documents
Links to PDF / Office documents. "Accessible document verification required" — link detection alone never claims PDF accessibility.
03 · SCORE METHODOLOGY
How the website accessibility score is calculated
The score is transparent and reproducible — never an arbitrary percentage.
Penalty model
The score starts at 100. Each normalized issue group subtracts a weighted penalty by severity:
| Severity | Penalty / group |
|---|---|
| CRITICAL | 10 points |
| HIGH | 6 points |
| MEDIUM | 3 points |
| LOW | 1 point |
| INFO | 0 points (informational) |
Normalization & frequency
Repeated identical issues are normalized into one issue group. For example, 150 images missing alt text is one "Missing alt text" group, not 150 penalties. A frequency factor (up to 2.5×) increases the impact when an issue is widespread:
| Occurrences | Frequency factor |
|---|---|
| 1 | 1.0× |
| 10 | 1.5× |
| 100 | 2.0× |
| 1,000+ | 2.5× (capped) |
Formula: penalty = severity weight × frequency factor, where frequency factor = min(1 + log₁₀(occurrences) × 0.5, 2.5). Final score = 100 − total penalty, clamped to 0–100.
Score bands
Bands describe the automated result — they are not WCAG conformance levels.
Excellent
Good
Needs Improvement
Poor
Critical
What the score is NOT
The score is an automated accessibility score, not a "WCAG compliance score", an "IS 17802 compliance score", or a legal determination of compliance. It measures accessibility characteristics detectable by automated checks only.
04 · STANDARDS MAPPING
Standards references policy
Every automated finding supports standards references where verified. The scanner maps:
- WCAG 2.1 and WCAG 2.2 — success criteria are only attached when they are known and verified for the specific check (for example, missing alt text maps to WCAG 1.1.1; missing page title maps to WCAG 2.4.2).
- WAI-ARIA — treated as a technology specification (name, role, value, relationships), not a compliance framework. Native semantic HTML is preferred.
- IS 17802, EN 301 549, Section 508 — shown as "Standards mapping pending verification" because the scanner never invents clause numbers it has not verified.
No WCAG criterion number, IS 17802 clause or Section 508 reference is ever fabricated. If a mapping has not been verified, the report says so explicitly.
05 · VENDOR-NEUTRAL DETECTION
Accessibility solution detection & A11yGo coverage
Solution detection
The scanner detects whether the website already provides accessibility functionality — A11yGo, a third-party widget (UserWay, accessiBe, EqualWeb, AudioEye, One Click Accessibility, and others), custom/native controls, multiple solutions, or none at all.
Detection uses script URLs, CDN paths, DOM/CSS signatures and known vendor fingerprints. A website with no toolbar is never treated as an accessibility failure — it is simply reported as "no accessibility solution detected".
A11yGo Enhancement Coverage
If A11yGo is installed, a separate metric — A11yGo Enhancement Coverage — reports the percentage of applicable A11yGo features detected as available (e.g. text resize, high contrast, reduce motion, big cursor, dyslexic font, text-to-speech).
Coverage = detected-and-available features ÷ applicable features. It never changes the website accessibility score, and it is not presented as compliance. If A11yGo is not installed, coverage is simply "not available".
06 · MANUAL REVIEW
What automation cannot judge
The report clearly separates 18 manual review items from the automated score.
Assessment disclaimer
This assessment uses automated technical checks and identifies potential accessibility issues that can be detected automatically. Automated testing cannot identify every accessibility issue and does not replace manual accessibility evaluation, assistive technology testing or testing with people with disabilities. References to WCAG, IS 17802 and other standards are provided for informational and technical guidance. Results should not be interpreted as certification, legal advice or a determination of compliance.