Thiago Piacentini
Web Accessibility Engineer & web accessibility advocate — Perth, WA
Bridging technical implementation with inclusive design.
Recent posts
- Removing the focus outline does not make your UI cleaner. It makes it unusable for keyboard users.
One line of CSS has been quietly breaking keyboard navigation across the web for years. What outline: none actually does, what WCAG requires, and how to fix it correctly.
- Which screen reader and browser combinations should you prioritise in testing?
Global survey data tells you where to start. Your own analytics tell you where to focus. Here is what the WebAIM Screen Reader User Survey #10 reveals about real user environments.
- Testing with one screen reader and one browser is not a test. It is a sample.
Screen readers and browsers do not share a single consistent implementation of accessibility APIs. Each combination has its own behaviour, its own gaps, and its own failures.
- A systematic approach to keyboard accessibility testing
Keyboard testing only works when it is systematic. Here is the checklist I use on every interface I audit, and why a checklist protects against our own perception.
- A page with broken heading structure gives screen readers no map to follow
When heading levels are skipped, repeated, or placed out of order, the impact goes beyond visual inconsistency. For users who navigate by keyboard shortcuts, a broken heading hierarchy can make a page impossible to use.
- 10 things that affect accessibility before the first line of code
Accessibility is often discussed at the code level. But many of the decisions that define whether a product is accessible or not happen much earlier than that.
- Ignoring accessibility is not a technical debt. It is a business risk.
When accessibility is skipped, the cost rarely stays technical. It shows up in users who leave, in reach that never grows, and in legal exposure that was entirely avoidable.
- Accessibility starts long before the first line of code
Most teams treat accessibility as a final step — something to check before launch or fix after an audit. By then, the decisions that matter most have already been made.
- Behind every WCAG criterion, there is a real person
Accessibility is not just about guidelines — it's about real people. Semantic HTML is what connects your code to them.
- Semantic HTML isn't just about accessibility — it also affects how search engines read your content
Semantic HTML improves accessibility and also defines how search engines understand, index, and rank your content.