Materialize CSS form components lack ARIA roles and default focus outlines, creating accessibility uncertainty

Direct answer

Use the Materialize CSS release locked in package.json or package-lock.json as the verification baseline. If the dependency is unpinned, treat Materialize CSS 1.0.0 as the reference stable release; do not assume 0.x or an unnamed fork has the same markup or focus behavior. Add explicit ARIA attributes to your existing markup or to DOM generated by Materialize after JavaScript initialization, then load a scoped accessibility stylesheet after Materialize and your custom theme. Do not edit framework source files.

Confirmed facts versus likely explanation

Confirmed: Materialize CSS classes are presentational. Screen-reader semantics come from HTML attributes and implicit roles, not from framework classes. Removing default focus outlines impairs keyboard navigation, and visible focus must be present in the final built CSS.

Likely: Materialize's enhanced select, checkbox, radio, and file widgets hide native controls and insert presentational markup, so ARIA may need to be applied to generated elements after initialization. Custom theming loaded after Materialize can suppress focus outlines or change focus colors, which is why the problem may appear only in production builds. Version differences across 0.x, 1.0.0, and forks are unverified for this specific issue.

Steps for this case

1. Confirm the pinned version: npm ls materialize-css or inspect package.json and package-lock.json. Record whether it is 1.0.0, an older 0.x release, or a fork.
2. Add ARIA to native form controls where labels are not already programmatic: use for/id, aria-label, aria-labelledby, aria-required, and aria-describedby. Do not add redundant roles such as role="checkbox" to input type="checkbox".
3. For Materialize-enhanced widgets, inspect the generated dropdown or wrapper after initialization and add missing roles such as role="listbox" and role="option" only where the framework does not already provide them.
4. Load a scoped focus stylesheet after your custom theme, for example:

   .materialize-form input:focus-visible,
   .materialize-form select:focus-visible,
   .materialize-form textarea:focus-visible {
     outline: 2px solid currentColor;
     outline-offset: 2px;
   }

   Avoid !important unless a later theme rule still overrides the outline; prefer equal or higher specificity instead of editing Materialize source.
5. For server-side validation, set aria-invalid="true" on the field and aria-describedby to the error message element's ID; do not rely on color alone.

Verification

• Open a rendered form in DevTools, initialize the Materialize select, and inspect generated items for role="listbox" and role="option".
• Tab through the form in the final themed build and confirm every interactive element shows a visible focus indicator; check computed styles for :focus-visible or :focus.
• Use an accessibility inspector or screen reader to confirm labels are associated and invalid fields announce aria-invalid and aria-describedby errors.
• Repeat all checks after building with your custom theme loaded after Materialize.

Assumption: this guidance targets Materialize CSS 1.0.0 behavior; older 0.x versions may generate different DOM. Uncertainty: the exact generated markup for datepickers, timepickers, and custom selects varies by version and must be verified in your build.

Missing diagnostic detail: Is your custom theme stylesheet loaded after Materialize CSS in the final build? This determines whether focus-outline restoration requires a post-theme stylesheet or only scoped overrides.