WebAble

Inspiration

Many websites unintentionally exclude people because of small accessibility issues: missing image descriptions, weak color contrast, unlabeled form fields, confusing heading order, or buttons that screen readers cannot understand. These problems are easy to miss during development, especially when teams are moving quickly.

AccessLens was inspired by the idea that accessibility checks should feel immediate, understandable, and practical. Instead of only showing technical warnings, the project helps developers understand what is wrong, why it matters, and how to fix it.

## What it does

AccessLens is a web accessibility auditing tool. A user can enter a website URL or paste HTML, then AccessLens analyzes the page and returns a clear accessibility report.

The report includes:

• An accessibility score
• Issues grouped by severity
• Missing alt text detection
• Form label checks
• Button and link name checks
• Heading structure analysis
• Color contrast warnings
• Plain-language explanations
• Suggested fixes for common problems

The goal is not just to flag errors, but to make accessibility easier to act on.

## How we built it

We built AccessLens as a web application with a simple developer-focused workflow.

The frontend provides the audit interface, score summary, issue list, and recommendations. The scanning logic inspects HTML structure and common accessibility patterns, including semantic elements, headings, images, forms, links, and interactive controls.

The score is calculated from the number and severity of detected issues. A simplified version of the scoring model is:

$$ score = \max(0, 100 - \sum issuePenalty) $$

where higher-severity issues apply a larger penalty than lower-severity warnings.

Each issue includes context, impact, and a suggested fix so developers can quickly understand the next step.

## Challenges we faced

One challenge was turning accessibility rules into feedback that feels useful rather than overwhelming. Accessibility reports can easily become too technical, so we focused on making the output readable and action-oriented.

Another challenge was balancing scope. Full accessibility compliance is complex, and automated tools cannot catch every issue. We focused the MVP on high-impact checks that can be reliably detected and clearly explained.

Color contrast analysis was also challenging because real websites often use inherited styles, dynamic themes, and CSS variables. For the MVP, we prioritized practical detection and clear warnings while leaving room for deeper browser- based analysis later.

## What we learned

We learned that accessibility is not just a checklist. It is about making interfaces understandable, navigable, and usable for people with different abilities, devices, and contexts.

We also learned that developer tools are most helpful when they combine detection with education. A warning is useful, but a warning with a reason and a fix is much more actionable.

## What's next

Next, we want to improve AccessLens with:

• Live website crawling
• Browser-rendered contrast analysis
• PDF report export
• GitHub pull request comments
• CI/CD integration
• AI-generated repair suggestions
• WCAG guideline mapping
• Team dashboards for tracking accessibility progress over time

AccessLens aims to make accessibility review a natural part of building the web, not something teams only think about at the end.

Built With

• accessibility
• api
• auditing
• axe-core
• backend
• css
• developer
• express.js
• frontend
• html
• javascript
• jsdom
• node.js
• open
• react
• source
• tools
• typescript
• ux
• vite
• wcag
• web