# Attribute “aria-readonly” must not be specified on elements that have attribute “readonly”.

> Canonical HTML version: https://rocketvalidator.com/html-validation/attribute-aria-readonly-must-not-be-specified-on-elements-that-have-attribute-readonly
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

A field with the `readonly` attribute can't also have `aria-readonly="false"`: remove `aria-readonly` and let the native attribute set the state.

The `readonly` attribute on an `<input>` or `<textarea>` already tells browsers and assistive technologies that the user can't change the value. `aria-readonly="false"` claims the opposite, so the field exposes two conflicting states. The ARIA in HTML specification forbids `aria-readonly="false"` on any element that has `readonly`, and the validator reports it as an error.

This often comes from a component or template that always outputs `aria-readonly` from a flag that defaults to `false`, while `readonly` is added separately. Decide what the field should be. If users shouldn't edit it, keep `readonly` and drop `aria-readonly`. If they should, remove `readonly`. `aria-readonly` is meant for custom widgets, such as an element with `role="textbox"` or a grid cell, which have no native `readonly` attribute.

Writing `aria-readonly="true"` next to `readonly` doesn't trigger this error. That combination is only redundant, and the validator reports it as a warning.

## Invalid example

```html
<label for="account">Account ID</label>
<input type="text" id="account" name="account" value="AC-1042" readonly aria-readonly="false">
```

## Valid example

```html
<label for="account">Account ID</label>
<input type="text" id="account" name="account" value="AC-1042" readonly>
```