Two side-by-side bar charts showing model differences in accessibility. Panel (a) shows mean node-level Axe pass rate with plus-or-minus one standard error error bars. Claude Opus 4.6 and Grok 4 have the highest pass rates, followed by GPT 5.4 and DeepSeek V3.2, while Gemini 3.1 has the lowest. Panel (b) shows mean normalized schema scorescore with plus-or-minus one standard error error bars. GPT 5.4 has the highest scores, followed by Grok 4 and DeepSeek V3.2, then Claude Opus 4.6, while Gemini 3.1 has the lowest.

Accessibility of LLM-Generated HTML Form Components

Prompt and Circumstance: Evaluating Accessibility in LLM-Generated HTML Form Components. Yumeng Ma, Jacob O. Wobbrock, Joe Devon, Aaron Gustafson, Michael Fairchild, Jennifer Mankoff, Venkatesh Potluri. ASSETS 2026. (doi) (Code & Data on A11yhood)

Diagram showing the PACE workflow. A user selects a test configuration consisting of four factors: model (e.g., GPT, Claude, etc.), system instruction (fixed guidance for output behavior), component specification (form component to be generated with label and attribute), and request variant (a prompt template). These factors are combined to generate test cases, where each combination forms one case. Each test case is then executed by a model to produce HTML output. The example output shows a labeled text input field generated from the prompt.
The PACE workflow. The user first creates an experiment by defining models, system instructions, component specifications, and request variants. The testbed then constructs test cases by enumerating combinations of these factors. Each test case is executed to produce an HTML output.

Large language models (LLMs) are used to generate user interface (UI) code, yet the accessibility of this code is difficult to evaluate in a controlled way. Existing evaluations typically examine full-generated webpages or loosely specified tasks, which makes it difficult to determine where accessibility outcomes come from. We introduce PACE for “Prompt Accessibility Controlled Evaluation,” a benchmarking testbed for controlled evaluation of accessibility in LLM-generated HTML form components. Using PACE, we evaluated the accessibility of 58 form components generated by five developer-centric LLMs with variations across three system prompts with increasing accessibility guidance, and three request variants containing increasing detail about each form components. We collected 10 trials per configuration for a total of n = 26, 100 outputs. Our findings show that accessibility in LLM-generated code moved with prompt construction and with the circumstance around it (e.g., model, form component, and measure used to assess the output). This pattern calls for evaluation designs that can better separate sources of variation in the accessibility of LLM-generated code.

Leave a Reply

Your email address will not be published. Required fields are marked *