How to track WCAG and European Accessibility Act fixes in monday.com

By Kayabyte

Short answer: monday.com can run accessibility work well enough for most teams. Create one board per client or site, with one item per finding, and add columns for the page, the WCAG criterion, the severity, the owner, the status and the retest date. Use automations to send fixed items to whoever retests them, and a dashboard to show what is still open. monday.com does not find accessibility problems, does not know WCAG, and does not produce an accessibility statement. Those parts stay with your audit tools and your people.

This guide is for agencies and in-house teams that fix websites or apps after an audit. It covers the board, the routine around it and where it stops. It is not legal advice. Menu names and plan limits change over time, so check your own account when a step looks different.

What the European Accessibility Act asks for

The European Accessibility Act (EAA, Directive (EU) 2019/882) has applied since 28 June 2025. These are the points that shape a tracker:

It covers listed products and services for consumers. The services include e-commerce, banking, e-books, electronic communications and parts of passenger transport. A site that only sells to businesses may fall outside it. Your client’s lawyer decides that, not the tracker.
Very small service businesses are exempt. A microenterprise employs fewer than 10 people and has an annual turnover or balance sheet total of no more than EUR 2 million. This exemption covers services, not products.
Providers must explain how the service meets the requirements. Annex V asks for this information in the general terms or an equivalent document. Keep your evidence where you can find it.
There is a transition for some older setups. Member states can allow products already used to provide a service to continue until 28 June 2030, and service contracts agreed before 28 June 2025 can continue until they end, for up to five years.
Each country enforces its own version. Penalties and details differ by member state, so check the national law where your client operates.

Most teams work to WCAG 2.1 level AA, because the European standard EN 301 549 builds on it. Ask for legal advice on what your client must meet. WCAG 2.2 adds further criteria, and content that meets 2.2 also meets 2.1.

Step by step: an accessibility board

Create the board. Start a new board, name it after the client or site, and rename the first column to Finding. Write each name so that it makes sense alone, such as “Checkout: card error is not announced”.
Add groups. Use Open, In progress, Ready for retest, Closed and Won’t fix. Groups give you a quick view of where the work stands.
Add the columns. A good starting set:
- Link: the page or screen.
- Dropdown: WCAG criterion, such as 1.4.3 Contrast or 2.1.1 Keyboard.
- Status: severity (Blocker, Serious, Moderate, Minor).
- Dropdown: found by (manual test, screen reader, automated scan, user report).
- People: who fixes it, and a second People column for who retests it.
- Status: state (Open, In progress, Ready for retest, Failed retest, Closed).
- Date: retest date.
- Files: screenshots, recordings and evidence.
- Long text: the steps to reproduce and the expected result.
Load the audit. Most audit reports can be exported to a spreadsheet. Clean up the columns, then import the file into the board. One finding that affects a shared component should be one item with the affected pages listed, so the team doesn’t fix it 40 times.
Add the automations. Useful rules are “when state changes to Ready for retest, notify the retester”, “when state changes to Failed retest, notify the fixer” and “when state changes to Closed, move the item to the Closed group”. Check the exact recipes in your account.
Make a dashboard. Chart open findings by severity and by WCAG criterion, and add a number for open blockers. Use one dashboard per client if you report to them.
Decide how the client sees it. You can invite clients as guests or show them a dashboard or shared view. Plans and permissions differ, so test it with a client account first.

Habits that keep the tracker honest

Only the retester closes an item. The person who fixed a finding shouldn’t also confirm it.
Test with real assistive technology. Automated scans catch only part of what WCAG covers, so a clean scan doesn’t mean a clean site.
Record decisions. If a fix is left out, note why, who decided and when. If someone claims a disproportionate burden under Article 14 of the directive, that needs its own assessment and record, not only a status label.
Keep the WCAG version on the board. Name the version and level you test against in the board description, so a later audit compares like with like.
Plan the next round. New pages and features can bring back old problems. Add a recurring item for the next audit.

Where it stops

No detection. monday.com doesn’t scan pages. Findings come from your audit, your tools or your users.
No WCAG knowledge. The criterion is only a label you pick, and you maintain the list.
Repeated setup. Each new client means a new board. A saved board template helps, but changes to the template don’t reach the boards you already made.
No scope check. A board can’t tell you whether the EAA applies to a client.
No statement. You still write the accessibility information yourself. The board can only hold what you need for it.
No conformance record by itself. Closed items show the work that was done. They don’t prove that a site conforms.
Portfolio view. To see open blockers across all clients you need a dashboard over many boards, and how many boards one dashboard can hold depends on your plan.

Should there be an app for this?

We don’t have one. We make apps for monday.com, and we are looking into whether agencies need more than the board above: for example a ready WCAG 2.1 and 2.2 list, an audit import, a client-facing progress page that needs no seat, and a record of what was retested and when.

If you run accessibility work on monday.com, tell us what’s missing at support@kayabyte.dev. We read every reply, and we’ll only build it if real teams need it.

FAQ

Does the European Accessibility Act apply to my client’s website? It depends on what the site offers, whether it serves consumers, and the size of the business. E-commerce for consumers is covered, and very small service businesses are exempt. Ask a lawyer familiar with the national law.

Is the EAA deadline still ahead? No. It has applied since 28 June 2025. The transition rules only cover certain older products and contracts.

Which WCAG version should we track against? Most teams use WCAG 2.1 AA because EN 301 549 builds on it. Testing against 2.2 AA also covers 2.1, so it’s a reasonable choice if your client agrees.

Does monday.com have a built-in accessibility tracker? We didn’t find one as of November 2026. You build it from ordinary columns, groups and automations, as shown above.

Is this legal advice? No. It shows how to organize the work. The law and your contract decide what has to be done.

monday.com is a trademark of monday.com Ltd. Kayabyte is an independent developer and is not affiliated with or endorsed by monday.com.