Frontend on Osmar Petry

Web Accessibility V3 — Topics cheat-sheet & decision guide

Mon, 01 Sep 2025 00:00:00 +0000

Summary

Course map covers Screen Readers, Accessible HTML, ARIA, Focus Management, and Visual Considerations, plus Debugging & team process.
Aim: ship perceivable, operable, understandable, robust experiences (POUR) with practical exercises and team-ready debugging habits.

Topics → what to do (at a glance)

Screen Readers: learn how they work, enable them, write solid alt text, and test.
Accessible HTML: prefer semantic elements and set document language; fix invalid markup.
ARIA: add only when semantics aren’t enough; know roles, states, properties, names/descriptions, and live regions.
Focus Management: full keyboard support, skip links, logical Tab order, avoid focus traps, and review shortcuts.
Visual: check color contrast, reflow/zoom, reduced motion, and prefers-color-scheme; connect performance with accessibility.
Debugging: use linters/devtools, improve team workflows, go beyond compliance, and practice with hands-on exercises.

Decision heuristics

Semantics first → ARIA last. If a native element already communicates role/state, don’t add ARIA.
Keyboard is the truth. If it’s not operable with keyboard and visible focus, it’s not accessible.
Name, role, value: can a screen reader expose them correctly? If not, fix semantics, labels, or ARIA.
Respect user prefs: prefers-reduced-motion, prefers-color-scheme, and zoom/reflow without loss.

Team workflow

Set standards (WCAG targets, browser/AT matrix).
Lint & test early (HTML validity, axe, devtools).
Exercise mindset: practice with screen readers and keyboard on real UI (modals, forms, navigation).
Go beyond checklists: optimize usability for assistive technology users, not just box-ticking.

Dev checklist

Landmark structure (header, nav, main, aside, footer).
Page language (<html lang>).
Forms: <label> + programmatic names; error text announced.
Interactive controls are native or fully re-created (role, keyboard, focus, ARIA).
Focus order and visible focus style.
Contrast meets WCAG; no information by color alone.
Motion: provide a reduced motion path; avoid parallax autoplay by default.
Respect zoom/reflow at 200–400% without horizontal scroll.

References

Web Accessibility — All Topics (Frontend Masters companion site): https://web-accessibility-v3.vercel.app/topics
GitHub repo: https://github.com/marcysutton/frontend-masters-web-accessibility-v3

[[react-forwardRef|Forwarding Ref]]
[[svg-are-the-best|SVG are the Best]]

XState — model UI behavior correctly and make it testable

Sat, 12 Jul 2025 00:00:00 +0000

The problem we’re solving

Imagine you join a company that runs an e-commerce platform. Product asks you to build a search page — the kind of page every user hits dozens of times a day. It sounds simple: a text input, a button, show results.

But then reality kicks in. The page has to handle empty queries, network failures, slow connections, retries, and race conditions where a user submits a second search before the first one finishes. A junior developer might reach for a handful of useState calls — isLoading, hasError, data, submitted — and suddenly you’re juggling four booleans that produce sixteen possible combinations. Most of those combinations are impossible, but nothing in the code prevents them. A loading spinner stays visible after an error. A success message flashes before the data arrives. Bugs creep in not because the developer made a logic error, but because the model itself was never defined.

React ForwardRef

Wed, 15 Jan 2025 00:00:00 +0000

By default, React does not let a parent component access the DOM node of a child component. forwardRef breaks that boundary explicitly — the child opts in to exposing its DOM node (or instance) to whoever holds the ref.

The typical need is imperative control from a parent: focusing an input inside a design-system <Input> wrapper, scrolling a <List> to a specific row, or triggering animations on a child element. Without forwardRef, the parent would need to own the DOM directly, which defeats the purpose of encapsulation.

React.Suspense

Wed, 15 Jan 2025 00:00:00 +0000

React.Suspense is a boundary component that lets you declaratively specify a fallback UI while its children are “suspended” — waiting for code to load or, in frameworks like Next.js/Remix, for async data to resolve. It decouples the loading concern from the component that needs the data, keeping each piece focused on its own responsibility.

Why use Suspense

Suspense lets you declaratively handle loading states for code-splitting and async data (with frameworks that support it). It improves first-load performance and keeps your UI logic focused on states that matter.

SVG Are the Best

Wed, 15 Jan 2025 00:00:00 +0000

SVG and icon fonts can solve similar problems, especially for icons. However, icon fonts must be downloaded correctly and mapped to the expected glyphs. When that fails, users may see empty squares or broken characters. SVG does not have that problem because the graphic itself is rendered directly.

SVG vs. Font Icons

Both approaches can be used for icons, but SVG is usually the better choice.

Why SVG is better

It does not depend on a font being loaded correctly
It can be styled and animated with CSS
It scales well across screen sizes
It works well for diagrams, illustrations, and UI icons
It supports filters and visual effects
It is accessible when used correctly
It exists as structured markup in the DOM
It is code, so it can be versioned, reviewed, and edited easily

SVG Benefits

1. Interactive and stylable with CSS

SVG elements can be targeted directly with CSS. You can change properties such as fill, stroke, opacity, transform, and more.

useRef

Wed, 15 Jan 2025 00:00:00 +0000

useRef gives you a mutable container — { current: value } — that persists for the full lifetime of the component without triggering re-renders when changed. This makes it the right tool for two distinct jobs: holding a reference to a DOM node for imperative operations, and storing any mutable value that your component needs to remember across renders but that should not drive the UI.

The key mental model: useState is for values that should be shown; useRef is for values that should be remembered.

Testing Concepts Notes

Fri, 15 Jan 2021 00:00:00 +0000

BDD

BDD (Behavior Driven Development) is a method of testing where you use “Given” for the scenario, “When” for the environment of the action, and “Then” for the action.

Imagine AutoLot, a car dealership chain building an online vehicle marketplace. A product manager, a developer, and a QA engineer sit together and write this scenario in plain English:

Given a customer browsing the SUV category
When the customer clicks "Schedule Test Drive" on a 2024 Honda CR-V
Then the test drive request should appear as "pending" in the customer's dashboard

This is BDD in practice — the three roles agree on the expected behavior before any code is written. The npm package jest-cucumber lets you map these Gherkin-style scenarios directly to Jest tests.

Testing Library vs Enzyme

Fri, 15 Jan 2021 00:00:00 +0000

Introduction

Testing Library is built around a simple philosophy: the more your tests resemble the way your software is used, the more confidence they can give you. Its three core principles are: tests only break when your app breaks (not when implementation details change), you interact with your app the same way as your users, and built-in selectors find elements the way users do to help you write inclusive code.

Frontend on Osmar Petry

Web Accessibility V3 — Topics cheat-sheet & decision guide

Summary

Topics → what to do (at a glance)

Decision heuristics

Team workflow

Dev checklist

References

Related Notes

XState — model UI behavior correctly and make it testable

The problem we’re solving

React ForwardRef

React.Suspense

Why use Suspense

SVG Are the Best

SVG vs. Font Icons

Why SVG is better

SVG Benefits

1. Interactive and stylable with CSS

useRef

Testing Concepts Notes

BDD

Testing Library vs Enzyme

Introduction