Accessibility

Accessibility Approach

This project treats accessibility as part of the interface architecture. Native HTML semantics are preferred first, with ARIA used only when it adds information that native elements do not provide.

The site is designed around keyboard access, visible focus states, descriptive table relationships, responsive reflow, reduced-motion preferences, readable color contrast, light and dark themes, and clear navigation landmarks.

Semantic HTML and ARIA

Start with native HTML elements that already communicate meaning and behavior. Add ARIA only when the interface needs semantics, relationships, or states that HTML does not provide on its own.

• Use landmarks such as header, nav, main, and footer to organize the page.
• Use real button elements for actions and links for navigation.
• Connect sections and controls to descriptive labels with attributes such as aria-labelledby when appropriate.
• Use aria-expanded, aria-controls, and other ARIA states when they communicate information that is not already available through native HTML.
• Avoid adding ARIA when native HTML already provides the required semantics.

Keyboard Access and Focus

Interactive controls should be reachable and usable without a mouse, with a visible focus state that makes the user's current position clear.

• Keep interactive elements in a logical focus order that follows the visual and reading order.
• Use native interactive elements whenever possible so expected keyboard behavior is provided automatically.
• Avoid positive tabindex values that manually reorder keyboard navigation.
• Use :focus-visible to provide clear keyboard focus indicators without removing useful browser behavior.
• Make custom dialogs, disclosures, search controls, and other interactive components keyboard operable.

Forms and Accessible Names

Form controls need clear names and instructions so their purpose can be understood visually and by assistive technology.

• Associate visible label elements with their form controls.
• Use descriptive button and link text instead of relying only on surrounding context.
• Communicate required fields, instructions, and validation messages clearly.
• Use aria-label or aria-labelledby only when a visible label cannot provide the needed accessible name or context.

Images and Alternative Text

Alternative text should communicate the purpose of meaningful images without repeating information that is already available nearby.

• Give meaningful images alternative text that communicates their purpose or important information.
• Use an empty alt="" value for decorative images that do not add information.
• Avoid beginning alternative text with phrases such as "image of" when the image type is already communicated by assistive technology.
• Do not place important information only inside an image when it can also be provided as text.

Color and Contrast

Text, controls, focus states, and other meaningful interface elements should remain readable and distinguishable across the site's themes and states.

• Maintain sufficient contrast between text and its background.
• Keep links, controls, and focus indicators visually distinguishable from surrounding content.
• Do not use color as the only way to communicate meaning, status, or required action.
• Check contrast in both light and dark themes instead of assuming one set of colors works equally well in both.

Reduced Motion

Respect the user's motion preference by reducing nonessential animations and transitions without removing information or functionality.

Use prefers-reduced-motion to remove or reduce nonessential movement while preserving the information and functionality the interface provides.

Responsive Reflow

Content should reflow and remain readable and usable as the viewport or text size changes instead of depending on a fixed screen size or orientation.

• Allow text and interface content to wrap naturally.
• Avoid fixed dimensions when they prevent content from adapting to available space.
• Make navigation and interactive controls usable at smaller viewport widths.
• Test layouts at multiple widths and with increased text size to catch clipping, overlapping, and horizontal scrolling.

Accessible Tables

Data tables should communicate the relationships between their headings and values so the information remains understandable when it is read with assistive technology.

• Use tables for tabular data rather than page layout.
• Use a caption to identify or describe the table when its purpose is not already clear from context.
• Use th elements for headers and identify their relationship with scope when appropriate.
• Keep the table structure as simple as possible while preserving the relationships in the data.

Live Regions

Dynamic interface updates sometimes need to be announced when they happen without moving keyboard focus away from what the user is doing.

An aria-live="polite" region can communicate non-urgent updates, such as changing search result counts, while allowing the user's current interaction to continue.

Site Accessibility Features

• Skip navigation to move directly to the main content.
• Keyboard-operable navigation, dialogs, disclosures, search, favorites, and copy controls.
• Semantic tables using captions, column headers, and row headers.
• Visible focus indicators that remain distinct in light and dark themes.
• Reduced-motion support through prefers-reduced-motion.
• Search result status messages announced through aria-live="polite".
• Text and layouts that reflow instead of depending on fixed viewport dimensions.

Accessibility Feedback

If you encounter an accessibility problem, please use the portfolio link in the site header or footer to contact me and include the page and feature involved.