Accessly

Accessly Poster

Inspiration

People who need accessibility accommodations often repeat the same process for every conference, workshop, seminar, university event, or community activity: searching for accessibility information, finding the correct contact or form, explaining their needs again, checking request timing, sending a request, following up, and waiting for confirmation.

We wanted to reduce that repetitive coordination.

That led us to build Accessly — an AI accessibility coordination agent that lets users save their accessibility needs once and then helps coordinate them across future events.

Our goal is simple:

Accessibility needs should not have to be re-explained from scratch for every event.

What it does

Accessly turns an event link into an actionable accessibility workflow.

A user saves their accessibility needs, such as wheelchair access, live captions, ASL interpretation, or accessible parking, and then pastes an event URL.

Accessly:

Browses the official event website.
Extracts verified event details such as the date, time, location, organizer, and format.
Checks each saved accessibility need against official information.
Classifies each need as:
- Confirmed
- Not Confirmed
- Not Applicable
- Unknown
Finds the official accommodation request form, email, or accessibility contact when action is needed.
Checks any request deadline or preferred notice period.
Prepares an accommodation request.
Shows the exact recipient, subject, and message to the user for approval.
Sends the request only after explicit user approval.
Creates a tracked request and can later check organizer replies and update the status.

Accessly is designed as a human-in-the-loop agent, not an autonomous system that acts without the user.

How we built it

We built Accessly using the Strands Agents SDK with Amazon Bedrock and Claude Sonnet for reasoning, event understanding, request drafting, and reply interpretation.

The agent has access to a focused set of tools for:

Reading the user's saved accessibility profile
Calculating event timing and notice periods
Browsing real event websites
Sending approved accommodation emails
Creating tracked requests
Checking replies
Updating request statuses

For real web navigation, we use Playwright with Chromium. This became important because many event websites are dynamic and cannot be reliably analyzed using simple HTTP requests.

The backend is built with FastAPI, which connects the Strands Agent to our React + Vite frontend.

Instead of showing users one large raw AI response, the frontend transforms the results into structured sections such as:

Event Details
Accessibility Check
Recommended Action
Email Draft
My Requests

For email coordination, Accessly uses Gmail SMTP and IMAP. During development, we use a strict Test Mode that redirects outgoing requests to a controlled inbox instead of real organizers.

For deployment:

The frontend is hosted on Vercel
The Dockerized FastAPI backend runs on Northflank
The agent uses Amazon Bedrock
Chromium runs inside the deployed backend container

Challenges we ran into

One of our biggest challenges was working with real event websites.

Some websites blocked normal HTTP requests, which pushed us to use a real Chromium browser with Playwright. Even with browser automation, some sites use authentication, CAPTCHA, or bot protection, so Accessly needed to handle cases where information could not be verified.

Another challenge was making the agent safe enough to interact with real organizations.

We designed several safeguards:

Accessly never assumes an accommodation exists without official evidence.
If information cannot be verified, it returns Unknown.
It does not invent personal information or form fields.
It does not submit real organization forms during development testing.
It requires explicit approval before sending any request.
Failed sends are not automatically retried.

We also faced deployment challenges because our backend needed to support FastAPI, Strands, Playwright, Chromium, Amazon Bedrock, and email functionality in the same runtime.

We solved this by creating a Docker-based production environment and validating it directly in the deployed Northflank container.

Accomplishments that we're proud of

We are especially proud that Accessly became more than a proof-of-concept chatbot.

It can perform a complete multi-step agent workflow:

Understand → Browse → Verify → Decide → Draft → Ask for Approval → Act → Track → Follow Up

We successfully tested Accessly against real public university event pages, including events from:

University of Michigan
Syracuse University
University of Washington
Stanford University

We also built and tested:

Dynamic event extraction
Per-accommodation reasoning
Virtual vs. in-person applicability
Notice-period calculations
Official request-channel discovery
Human-approved email sending
Request IDs and status tracking
Reply checking and status updates
A structured product interface instead of raw AI output
A publicly deployed frontend and backend

Our production container smoke test successfully validated:

Strands/browser imports
FastAPI startup
/health
Headless Chromium

What we learned

This project taught us that building an effective AI agent is very different from simply connecting an LLM to a chat interface.

The most important part was designing the workflow around tools, verification, state, safety, and user control.

We also learned that real-world browser automation introduces uncertainty. Websites change, some block automated access, and not every source can be verified. Because of that, knowing when to return Unknown is just as important as finding an answer.

Another major lesson was the importance of structured outputs. Early versions of Accessly returned long agent responses, but turning those results into event cards, accessibility statuses, request drafts, and tracked actions made the system much more usable.

Finally, deploying the full system helped us understand how frontend, API, agent reasoning, browser automation, cloud hosting, and external services all need to work together for an agent to become a real product.

What's next for Accessly

The next major step is moving user profiles and request tracking to persistent cloud storage instead of lightweight local storage.

We also want to expand Accessly with:

Multi-user accounts and authentication
Persistent request history
More event-platform integrations
University accessibility-office integrations
Better handling of authenticated event websites
Richer notifications and follow-up workflows
Organizer-side integrations
Accessibility request analytics
More reusable accessibility preference profiles

Long term, we want Accessly to become a reusable accessibility coordination layer across events, universities, conferences, and professional communities.