Published
9 MIN READ
Accessible Website: What Brazilian Law Requires of Companies in 2026
An accessible website is one a person with a disability can use without help: navigate with the keyboard alone, listen to the page with a screen reader, fill out a form and understand a video. In Brazil, the Brazilian Inclusion Law (LBI), from 2015, requires companies headquartered or represented in the country to keep their website accessible.
What the law still lacks is a technical regulation. In July 2026, a federal court denied the request for the government to make the ABNT NBR 17225 standard (ABNT is Brazil's national standards body) mandatory for private companies as well. The obligation still stands; a mandatory technical benchmark and a specific penalty do not.
Wama builds websites in Framer, more than 50 of them published on the platform, and this article draws on that work to separate what comes ready-made from what depends on whoever designs and whoever writes. Here you'll see what to put in the proposal, alongside what goes into the scope of a corporate website.
What does the law require of a company website in 2026?
The requirement is in article 63 of Law 13,146 of 2015: accessibility is mandatory on websites maintained by companies headquartered or commercially represented in the country, in line with internationally adopted best practices and guidelines. It applies to the corporate website, to a campaign landing page and to the online store, regardless of company size.
The article sets no technical criteria, no compliance deadline and no fine of its own. That's why the law has been in force for a decade and almost no company can say whether it complies. When ABNT released NBR 17225 in March 2025, Ceweb.br, the NIC.br center that coordinated the work, stated that less than 3% of Brazilian websites follow accessibility standards, according to Teletime.
What changed with the July 2026 decision?
On June 10, 2026, the Federal Public Prosecutor's Office (MPF) in São Paulo filed a public civil action against the federal government, case 5017981-57.2026.4.03.6100. It asked the government to issue, within 60 days, an act making NBR 17225 the mandatory benchmark for public and private legal entities, according to the MPF press release.
In the preliminary injunction signed on July 1, 2026, the 9th Federal Civil Court of São Paulo granted only part of it. It denied the regulatory act, on the grounds that it would reach other branches of government, federal entities and private parties. And it ordered the federal government to present, within 180 days, a transition plan for federal websites, with a daily fine of US$ 2,000 for non-compliance. In a TCU (Brazil's Federal Court of Accounts) survey cited in the case, 88.54% of 366 federal agencies scored poorly on accessibility.
What exists | Status in October 2026 |
|---|---|
Obligation to keep the website accessible | In force for companies headquartered or represented in Brazil (LBI, art. 63) |
Mandatory technical benchmark | Doesn't exist; NBR 17225 is the technical reference |
Specific sanction in a regulation | Not defined |
MPF public civil action | Ongoing; the July 1 injunction applies only to the federal government |
For private companies, the decision created neither a new obligation nor a safe harbor. The MPF noted that e-commerce, services and finance companies use the lack of a technical guideline to justify inaccessible websites. Counting on that gap is betting it will last, and in the financial sector the requirement adds to the rules that already weigh on the website of a regulated company.
What ABNT NBR 17225 asks for, in plain buyer's language
NBR 17225 gathers 146 guidelines, split between requirements and recommendations, written by 178 specialists based on WCAG 2.2, the W3C guideline. Regular conformance means meeting every requirement, which is equivalent to WCAG levels A and AA. Full conformance adds the recommendations, equivalent to AAA, with a justification for whatever doesn't apply, according to Ceweb.br's presentation of the standard.
The standard's sections turn into direct questions about your website:
Keyboard: can you navigate and trigger everything without a mouse?
Images: does every informative image have a text description?
Structure: do headings, regions and lists make sense to someone listening to the page?
Links and forms: is the destination clear, and does the error explain how to fix it?
Colors: does information not depend on color alone, and is the contrast readable?
Media and motion: are there captions, an option to reduce animation and enough time to finish the task?
The standard also lists problematic items: CAPTCHA, facial recognition, content that only appears under the cursor, third-party content and custom components. These criteria belong on the list of what to demand from whoever designs the interface, because most of them are decided in the layout.
What should go in the website proposal?
Accessibility that isn't written in the proposal wasn't hired. At Wama, whatever isn't written in the proposal is out of scope, and the rule applies to any vendor: if the document doesn't say which level will be delivered, each side will assume a different one.
Target level: regular conformance with ABNT NBR 17225:2025, equivalent to WCAG 2.2 level AA, on the pages in scope.
Verification method: an automated tool plus manual testing with keyboard and screen reader.
Third-party list: embedded chat, map, video and CRM form, which the website vendor doesn't control.
Content owner: who writes the copy and the image descriptions for the first version.
Documentation: a short report of what was checked and an accessibility statement on the website, with a channel to report barriers.
The fourth item matters more than it seems. At Wama, who writes the copy depends on the budget hired and is a scope item, and the copy is where the heading order, the name of each link and the description of each image come from. Bringing the requirement into the website brief from the start avoids discovering the gap during review.
Accessibility goes into the price like any scope requirement, because manual testing and content review take hours. It's one more of the factors in what makes a website quote change, and it's cheaper before the first layout than after launch.
What to check at delivery
Five tests that don't require a specialist:
Tab from start to finish: focus shows on every link and button, in logical order, and nothing traps the keyboard.
Screen reader on your phone: VoiceOver on iPhone or TalkBack on Android, on the home page and the form.
Images: informative ones have descriptive alt text; decorative ones are ignored.
Headings: one H1 per page and H2 and H3 in order, without skipping a level because of size.
Zoom and motion: at 200% zoom the text doesn't get cut off, and with reduced motion on in the system, animations stop.
Automated tools help, but they don't settle it: Ceweb.br's presentation recommends combining manual and automated tests. For the same reason, a Lighthouse score doesn't prove accessibility on its own.
At Wama, there's a warranty period after delivery, with fixes at no cost. That window is where keyboard and screen reader testing pays off most, because a problem found is still a fix, not a new project.
After launch: who keeps the website accessible?
Part of accessibility comes from the tool. According to Framer's accessibility guide, updated in September 2026, the editor assigns semantic tags to text styles, marks header, nav and footer, accepts alt text on images, changes the tab order and turns off animations for people who asked for less motion. The guide itself says the real impact lies in the meaning someone gives to each element.
Images without alt text, scanned PDFs, videos without captions and links with generic text are typical breakages after launch, and they originate in content, not code.
At Wama, the project is transferred to the client's account and their team is trained to use the CMS; people who only publish content use the editor role. From then on, describing each new image is up to whoever publishes it, and the accessibility rules fit into the same training that teaches how to publish content through the CMS without touching the design.
Common mistakes
Treating a widget as compliance. A script added on top doesn't write alt text, order headings or label forms.
Reading the lack of regulation as an exemption. The July decision denied the regulatory act, not the law.
Hiring without a written level. "The website will be accessible" isn't a verifiable criterion; "regular conformance with NBR 17225" is.
Only asking whether the website is accessible. The answer is always yes; the questions worth asking the agency before you sign ask for level, method and documentation.
Frequently asked questions
Is a private company's website required to be accessible?
Yes. Article 63 of the Brazilian Inclusion Law, from 2015, makes accessibility mandatory on the websites of companies headquartered or commercially represented in Brazil, in line with international guidelines. What's missing is the regulation that defines the technical benchmark and the sanction. As of October 2026, that regulation still doesn't exist, and the legal obligation remains in force.
Is ABNT NBR 17225 mandatory?
Not on its own. An ABNT standard becomes mandatory when a law or regulation adopts it, and the July 1, 2026 injunction denied the request for the government to do that through a regulatory act. Even so, it's the clearest technical reference for complying with article 63 and is worth writing into the contract.
What's the difference between NBR 17225 and WCAG?
NBR 17225 was built from WCAG 2.2, by the W3C, and anyone who meets the Brazilian standard also meets WCAG. Regular conformance corresponds to levels A and AA; full conformance to AAA, with a justification for whatever doesn't apply. The standard's advantage is that it's written in Portuguese and aligned with Brazilian law.
Does an accessibility plugin or widget solve it?
Not on its own. A widget changes how the page is presented, but it doesn't write image descriptions, fix heading order or label form fields. NBR 17225 treats third-party content and custom components as problematic items. The foundation is still structure, content and manual testing with keyboard and screen reader.
Who is responsible for accessibility after the website goes live?
Whoever publishes the content. At Wama, the website lives in the client's account and their team is trained on the CMS, with an editor role for people who only publish. From delivery on, every new image, PDF or video depends on whoever uploads it, which is why the rule of describing images needs to be part of the training and the internal handbook.
If your website is about to be built or rebuilt, write the accessibility level into the proposal before the first layout, along with the testing method and who handles content. To scope your website with that criterion from the start, talk to Wama.
