❮ Previous

Accessibility States

  • Create inclusive and accessible UI interactions with proper state management.

  • Modern UI is not only about looking good -
    it must also be usable by everyone.

    This lesson introduces ARIA-based State Styling, which connects:

    • Accessibility

    • UI states

    • Screen readers

    • Real-world professional standards

      What Are Accessibility States ? 

      Accessibility states describe how assistive technologies understand UI elements.

      They communicate:

      • Whether something is expanded

      • Selected or not

      • Disabled

      • Busy

      • Hidden

      • Invalid

      These states are not visual by default -
      they are semantic states for accessibility.

      What is ARIA ? 

      ARIA stands for:

      Accessible Rich Internet Applications

      ARIA is a set of attributes that:

      • Add meaning to UI components

      • Help screen readers understand state

      • Support custom components (non-native elements)

      ARIA does not replace HTML -
      it enhances it when native semantics are missing.

      Why ARIA-Based State Styling Exists

      Problem:

      • Custom UI components don’t expose native states

      • <div> doesn’t tell screen readers anything

      • JavaScript-based UI hides real state from assistive tech

      Solution:

      • ARIA attributes communicate state

      • CSS can style based on those states

      Users get both visual and semantic feedback

      ARIA States vs Visual States

      Visual StateARIA State
      Hoveraria-expanded
      Focusaria-selected
      Disabledaria-disabled
      Loadingaria-busy
      Erroraria-invalid

      Visual states are for sighted users
      ARIA states are for assistive technology

      Professional UI supports both.

      What is ARIA-Based State Styling ?

      ARIA-based state styling means:

      Styling elements based on ARIA attributes instead of pseudo-classes.

    ARIA State Styling

    Shows how ARIA attributes can be used to control UI state styling. 

    /* ARIA attribute example */
<button aria-expanded="true">
  Toggle
</button>

    • CSS / Tailwind can react to this attribute value.

      Common ARIA State Attributes 

      Some frequently used ARIA states:

      • aria-expanded

      • aria-selected

      • aria-disabled

      • aria-checked

      • aria-busy

      • aria-invalid

      These states describe UI logic, not appearance.

      Why Tailwind Supports ARIA States

      Tailwind supports ARIA state styling because:

      • Modern UI uses custom components

      • Accessibility must scale with design systems

      • State-driven styling should stay declarative

      ARIA utilities allow:

      • Clean CSS-only logic

      • Accessible UI without hacks

      • Predictable component behavior

    Basic ARIA State

    Shows how ARIA attributes define element state for accessibility. 

    /* ARIA state attribute */
<button aria-expanded="true">
  Menu
</button>

    • This button is logically open, even if visually styled later.

      ARIA State Styling in Tailwind 

      Tailwind uses ARIA variants like:

      aria-expanded:bg-blue-500

      Meaning:

      Apply style when aria-expanded="true"

    ARIA Expanded Styling

    Shows how aria-expanded state controls styling using Tailwind. 

    /* style based on aria-expanded state */
<button
  aria-expanded="false"
  class="bg-gray-200 aria-expanded:bg-blue-500"
>
  Toggle
</button>

    • What’s Happening

      • Default → gray

      • When aria-expanded="true" → blue

      • Screen readers understand state

      • Visual users see feedback

        ARIA Disabled vs HTML Disabled

        HTML DisabledARIA Disabled
        Native behaviorSemantic only
        Prevents interactionDoes NOT block interaction
        Best for real inputsUsed for custom elements

        ARIA disabled must be paired with:

        • Visual styling

        • JavaScript behavior

      ARIA Disabled Styling

      Shows how aria-disabled controls UI styling for non-button elements. 

      /* style based on aria-disabled state */
<div
  role="button"
  aria-disabled="true"
  class="opacity-50 aria-disabled:cursor-not-allowed"
>
  Submit
</div>

      • This is common in custom buttons.

        ARIA-Based States Are NOT Decoration

        Important rule:

        ARIA is not for styling first - it is for meaning first.

        Wrong mindset:

        • “I’ll use ARIA to style UI”

        Correct mindset:

        • “ARIA describes state → UI reflects it”

          When ARIA State Styling is Required

          Use ARIA-based styling when:

          • You build custom components

          • Native HTML elements are not used

          • State is managed by JavaScript

          • Accessibility must be preserved

          Do NOT use ARIA when:

          • Native HTML already provides state

          • You can use <button>, <input>, <select>

            Accessibility Responsibility 

            ARIA:

            • Does not fix bad HTML

            • Does not replace semantics

            • Does not auto-make UI accessible

            ARIA supports accessibility -
            it does not magically create it.

            Common Mistakes

            • Using ARIA on native elements unnecessarily

            • Styling ARIA states without updating them logically

            • Forgetting keyboard support

            • Treating ARIA as optional

          ❮ Previous