Accessibility Statement
Commitment to Accessible Word Tools
MyAnagramSolver is designed to be usable by everyone. WCAG 2.1 AA is the target standard. This statement documents what is implemented, what is known to be limited, and how to report issues.
What Is Implemented
Semantic HTML and Heading Structure
Page structure uses semantic HTML5 elements: nav for navigation regions, main and role-annotated div elements for tool regions, h1 through h2 in logical hierarchy, table with th headers for tabular data, fieldset and legend for grouped form controls. Decorative elements use aria-hidden="true" to prevent screen reader announcement.
Each page has exactly one h1 element identifying the page subject. Subsequent headings use h2 for section titles. h3 elements appear within sections where needed. This heading hierarchy allows screen reader users to navigate page sections quickly using heading navigation.
Known Limitations
SVG chart descriptions: SVG diagrams on tool pages include role="img" and aria-label attributes describing the diagram purpose and general content. However, the numerical data presented graphically in charts is not fully exposed via data tables as an alternative format. Screen reader users may not access all information presented visually in charts.
Large result sets: A search may return up to 500 word result cards. Each card is individually focusable. Navigating 500 cards via keyboard or screen reader is impractical. The total result count is announced, but no pagination or chunking is provided to manage large result sets for keyboard users. This is a known limitation under active consideration.
Hover-only information: Some interface elements display additional information on hover (such as letter scores on result cards). This information is partially duplicated in ARIA labels but may not be fully equivalent across all screen reader configurations.
Formal testing gaps: The site has been developed following ARIA best practices. Formal testing with NVDA, VoiceOver, and TalkBack has not been completed for all tool configurations. User-reported issues are reviewed and prioritised.
Reporting Issues and Getting Help
To report an accessibility barrier, use the contact page. Include: the specific page or tool where the barrier occurs, the assistive technology being used (screen reader name, version, browser, and operating system), and a description of what you were trying to do and what happened instead. Accessibility reports are treated as high-priority.
This accessibility statement was prepared on 2026-07-27 and reflects the current state of the site. It is updated when significant changes are made to the site's accessibility implementation or when new limitations are identified.
Detailed Implementation — Technical Choices
The dark colour scheme (#16141a background, #e8e8f0 primary text) achieves a contrast ratio of approximately 12:1, deliberately chosen for readability in both bright and dim lighting conditions. The accent colour (#4f7df0 — a medium blue) is used for interactive elements, links, and section headings against the dark background. When this colour appears as a text colour, it maintains at least 4.5:1 contrast against the background. The accent colour is never used as the only visual indicator of interactivity — all interactive elements also have border, weight, or positional cues that do not depend on the blue colour alone.
Focus management follows a consistent model across all tool pages. When a user activates a search (pressing the search button or pressing Enter in the input field), keyboard focus does not move — it remains on the button or input. The result count update is announced via the aria-live region. This approach avoids the disorientation of focus jumping unexpectedly to a result region. Users who want to navigate results use Tab to move to the result grid after the count announcement.
Loading indicators (the spinning loader element shown during word database processing) use aria-hidden="true" to prevent screen readers from announcing a loading state for what is typically a sub-100-millisecond process. For longer operations (initial database load on very slow connections), the aria-live result count region serves as the completion signal.
The breadcrumb navigation on each page uses the nav element with aria-label="Breadcrumb" and aria-current="page" on the final breadcrumb item. This follows the ARIA Authoring Practices Guide pattern for breadcrumb navigation and allows screen reader users to identify their location within the site hierarchy without needing to navigate to a separate heading.
HTML tables are used only for genuinely tabular data (the Scrabble letter value table on the score calculator page, the word length distribution table on the statistics page). Table headers use th elements with appropriate scope attributes. This ensures that screen readers can associate data cells with their headers correctly. Decorative data presented in card layout uses div elements rather than table elements, following the guideline that visual grid layout of non-comparative data does not require table semantics.
Commitment and Roadmap
Accessibility improvements planned for future updates include: adding data table alternatives for all SVG chart content so numerical data is available to screen readers; implementing result pagination or virtual scrolling to reduce the keyboard navigation burden for large result sets; and conducting formal testing with NVDA and VoiceOver across representative tool pages. This statement will be updated as improvements are implemented.