How Startup Wars Is Building Toward WCAG 2.1 AA Compliance

WCAG 2.1 is a set of accessibility guidelines for digital content and applications. Level AA includes requirements that address keyboard access, structure, labels, contrast, focus, errors, status messages, and other parts of the user experience.

For schools, an accessibility claim should be specific. It should name the product version or date, scope, testing methods, known limits, and conformance level. A broad statement such as “WCAG compliant” does not provide enough information for a careful review.

Startup Wars’ current accessibility status

As of the April 15, 2026 Accessibility Conformance Report, Startup Wars Partially Supports WCAG 2.1 Level A and Level AA.

Startup Wars is building toward broader conformance. It does not currently claim full WCAG 2.1 AA conformance across every instructor route, student route, dialog, simulation state, or assistive technology scenario.

The evaluated product is a web-based education application with an instructor portal, student portal, and interactive entrepreneurship simulations.

What the evaluation covered

The documented scope includes:

• the instructor portal;
• the student portal;
• the simulation shell interface;
• heads-up displays, dialogs, and overlays;
• setup and report flows; and
• shared simulation support components.

The evaluation reviewed documented remediation, component inventory coverage, and automated accessibility smoke tests for selected flows. It also used Google Chrome on a 2019 MacBook Pro, NVDA, Apple VoiceOver, and keyboard-only navigation.

The full Accessibility Conformance Report provides the current scope and criterion-level details.

What this status means in plain language

Work has been done across key parts of the product. Some checks pass in the scope that was reviewed. Many rules still have a Partially Supports rating. More hands-on tests are needed across all routes and live game states.

This means a school should not treat the report as proof that each student task has no barrier. The report is a guide for the next step. Pick the tasks your class will use. Test those tasks with the access tools your students use. Ask about any known gap before the course starts.

Documented areas of accessibility work

Structure and navigation

Work has addressed headings, landmarks, lists, tables, tab patterns, dialogs, form labels, and labeled regions. These elements help users understand a page and move through it with assistive technology.

Keyboard interaction

Many pointer-only interactions have been changed to native buttons, links, tabs, radio controls, or other keyboard-operable patterns. Broader end-to-end keyboard validation is still needed across all live states.

Dialogs and focus

Documented improvements cover dialog controls, close and escape behavior, step flows, overlays, and focus order. Manual testing remains important because dynamic interfaces can behave differently across states.

Names, roles, and labels

Work has improved accessible names, roles, states, and values across portals and simulation support UI. These details affect how screen readers and voice-control tools identify controls.

Contrast and visible focus

Contrast and focus styling have been improved in several product areas. The report does not claim that every route and state has completed product-wide contrast and focus verification.

Status and error messages

The product has added or improved status announcements, form labels, validation messages, and error guidance in several workflows. Full validation across all dynamic states is still in progress.

A note about reflow and gameplay

WCAG 2.1 success criterion 1.4.10 addresses content reflow at narrow widths. The essential two-dimensional Phaser gameplay surface is treated as an exception where two-dimensional layout is fundamental to the activity.

That exception does not cover the surrounding web interface. Menus, dialogs, overlays, heads-up display text, controls, and support flows still need accessible behavior. The current report rates reflow as Partially Supports.

How schools should evaluate accessible edtech

An Accessibility Conformance Report is a starting point. Schools should also test the workflows their community will use.

Review the exact scope

Confirm which portals, features, and simulation states were evaluated. Ask whether a claim applies to the product today or to planned work.

Test representative tasks

Try signing in, finding an assignment, launching a simulation, making a representative decision, reviewing a report, and recovering from an error. Use keyboard-only navigation and the assistive technologies required by the institution.

Check zoom, focus, and dynamic updates

Review surrounding web content at increased zoom and narrow widths. Make sure focus remains visible and logical. Check whether status changes are announced in a useful way.

Ask about known barriers and support

A responsible vendor should state what remains incomplete. Discuss the process for reporting a barrier, receiving assistance, and finding an alternative path when needed.

Include disabled users in the review

Automated tests cannot represent every experience. When possible, include people who use assistive technology in product evaluation and pilot feedback.

A classroom access check

Run this check before a graded session:

• Share the lesson plan and key steps in advance.
• Ask students to sign in and find the task.
• Test the full path with a keyboard.
• Make sure focus is easy to see.
• Check the path with the screen reader your school uses.
• Zoom the web page and review text and controls around the game.
• Open, use, and close each dialog in the task.
• Trigger an error and check that the help is clear.
• Give students a private way to report a barrier.
• Plan another path if a barrier blocks the task.

Keep a short record of what you test. Include the date, browser, device, access tool, and task. This makes a bug report much easier to act on. It also helps the next teacher plan the same lesson.

Accessibility and classroom design

Accessible software is an important foundation, but it does not guarantee an accessible course. Educators still need clear instructions, accessible course materials, flexible participation, and support for approved accommodations.

For an entrepreneurship simulation, give students the activity plan in advance. Explain controls and goals. Check access before a graded session. Offer a way to report a barrier without requiring a student to disclose it to the whole class.

Get accessibility support

To report a barrier, email support@startupwars.com with the subject Accessibility Support, call (215) 821-8673, or use the accessibility issue form.

Schools with procurement or workflow questions can contact Startup Wars.