01 / 08
Summary
The main action on Brasil Participativo, voting on a proposal, had barriers that could stop a blind person from completing it. I designed and ran an accessibility audit of that flow with WAVE: 90 errors and 145 alerts across four pages, grouped by impact and mapped to WCAG success criteria. I turned the findings into a prioritized remediation plan, with a fix for every issue type.
02 / 08
Context and my role
Brasil Participativo is the Brazilian federal government's social participation platform, built on Decidim, an open-source participation software. Citizens use it to take part in public policy making, for example by proposing and voting on ideas in participatory processes such as Plano Clima.
I joined the project as a UX designer and today I am the Lead Product Designer. This audit was part of my work on the platform's accessibility. I defined the scope, ran the tests, analyzed the data and wrote up the findings.
03 / 08
The problem
A participation platform only works if everyone can use it. If the voting flow is not accessible, people with visual disabilities are left out of decisions about public policy, and the platform fails at its own purpose.
The question I set out to answer: how do the accessibility barriers in the platform's code affect a blind person trying to vote on a proposal?
04 / 08
Approach
I audited the most used flow on the platform, voting on a proposal, across four pages: the platform home, the Plano Clima home, the list of proposals and a specific proposal.
- Ran the WAVE tool on each page in September 2025, using Google Chrome in an incognito window.
- Counted every error and alert, grouped by type across the whole flow.
- Classified the findings by their impact on screen reader and keyboard users.
- Mapped each group to WCAG success criteria to make the impact traceable to a standard.
05 / 08
What I found
WAVE detected 90 errors of five types and 145 alerts of nine types. The most frequent errors were empty links (35) and missing form labels (27). The most frequent alerts were redundant links (62) and very small text (36).
I grouped the findings into three kinds of problems:
- Errors that break screen reader use: missing form labels, empty links and empty buttons. The user cannot tell what a control does, so the voting action itself becomes unreachable.
- Semantic issues that hinder keyboard navigation: empty headings, skipped heading levels and a missing first level heading. Blind users rely on headings to understand the page structure.
- Alerts that add friction: redundant links, very small text, justified text and very low contrast. They do not block the flow, but they hurt legibility and comprehension.
06 / 08
Why it matters
The counts only become a case for action when they are tied to real users and to a standard, so I mapped each group to WCAG success criteria.
| Problem group | WCAG criterion | Who it affects |
|---|---|---|
| Missing labels, empty links and buttons | 4.1.2 Name, Role, Value (A) and 3.3.2 Labels or Instructions (A) | Screen reader users cannot identify controls, so they cannot vote |
| Empty and skipped headings | 2.4.6 Headings and Labels (AA) | Blind users who navigate by headings lose the page structure |
| Low contrast and very small text | 1.4.3 Contrast Minimum (AA) | People with low vision or on poor screens |
The critical finding: the errors concentrate on interactive elements, exactly where the main action of the platform lives.
07 / 08
Action plan and outcome
I wrote a remediation plan that covers every issue type WAVE found: what causes it, how to fix it and which WCAG criterion it relates to. Priority follows the impact on the main action of the flow, voting on a proposal. 85 of the 90 errors (94%) are form fields, links and buttons without an accessible name, so they come first.
| Priority | Issue (occurrences) | Likely cause | How to fix it | WCAG |
|---|---|---|---|---|
| 1 | Empty link (35) | Icon-only or image-only links with no text | Add visible text, or an aria-label or alt text that says where the link goes | 4.1.2, 2.4.4 |
| 1 | Missing form label (27) | Inputs with no label associated to them | Add a label linked to the field, or aria-label and aria-labelledby when a visible label is not possible | 3.3.2, 4.1.2 |
| 1 | Empty form label (16) | A label element with no text inside | Write a descriptive label text, or remove the empty label and label the field correctly | 3.3.2, 1.3.1 |
| 1 | Empty button (7) | Icon-only buttons with no name | Add button text or an aria-label that describes the action | 4.1.2 |
| 2 | Empty heading (5) | Heading tags used for spacing or left without text | Remove the tag, or add the heading text | 2.4.6 |
| 2 | Missing first level heading (3) | Pages without an h1 | Add one h1 that names the page | 1.3.1, 2.4.6 |
| 2 | Skipped heading level (4) | Headings chosen for size, not for structure | Keep the order h1, h2, h3 and style size with CSS | 1.3.1, 2.4.6 |
| 2 | Very low contrast (9) | Text colors close to their background | Raise contrast to at least 4.5:1 (3:1 for large text) | 1.4.3 |
| 2 | Broken same-page link (4) | Anchor links pointing to ids that do not exist | Fix the target ids, including the skip link | 2.4.1 |
| 3 | Redundant link (62) | An image and its title as two links to the same place | Merge them into one link | 2.4.4 |
| 3 | Very small text (36) | Small font sizes | Use at least 16px for body text and avoid going below 12px | 1.4.4 |
| 3 | Redundant title text (13) | A title attribute repeating the link text | Remove the title attribute | 2.4.4 |
| 3 | Justified text (11) | Text aligned to both edges | Use left alignment | 1.4.8 |
| 3 | Long alternative text (3) | Alt text that is too long | Shorten it and move the detail to the page text | 1.1.1 |
WAVE alerts need human review, so some of the priority 3 items may turn out not to be real problems once someone checks them on the page.
The outcome of this work is the audit document itself: the findings, their impact on screen reader and keyboard users, and a fix for every issue type, ready to be used as an accessibility backlog. The plan has not been implemented in the platform yet, so this case is an audit and a recommendation, not a measured improvement. The natural next step is to fix priority 1, run WAVE again on the same four pages to compare the counts, and then test with a screen reader.
08 / 08
Reflections
WAVE is automated and detects only part of the possible barriers, so these counts are a lower bound, and the clear next step is testing with screen readers and with blind users. The pattern in the findings, with most errors concentrated in interactive elements, suggests that accessibility criteria were missing from the earlier stages of development. That is why I would bring them into design and handoff from the start, so the issues are prevented instead of found afterwards.