1

I have a user account page where I would like users to see a very basic form with the details of their account and, on page load, I would like this form to be in a read-only state. If users want to edit their account details, they can click on an edit button which will dynamically remove the readonly state of all of the input fields.

I have the following:

<button
  type="button"
  aria-pressed="false"
  aria-controls="EditAccount"
>
  Edit Account Details
</button>
<form id="EditAccount" class="profile-form">
  <label for="first_name">First name</label>
  <input type="text" name="first_name" id="first_name" value="Maria" readonly>
  <label for="last_name">Last name</label>
  <input type="text" name="last_name" id="last_name" value="Juana" readonly>
  <button type="submit" hidden>Submit</button>
</form>

Would using the aria-controls attribute on the button be enough to let users that use assistive technologies know that the button is toggling the readonly state of the entire form?

I've found similar questions on Stack Overflow on how to toggle the readonly state of an entire form but none that address my accessibility concerns.

Would I need to use a different approach to make it clear to these users that the form is toggling between an editable and readonly state?

TylerH
  • 20,799
  • 66
  • 75
  • 101
eballeste
  • 712
  • 1
  • 11
  • 23

1 Answers1

2

No, aria-controls is not what you want. While there are many ARIA attributes that allow toggling the value, and the toggling is announced by screen readers, there isn't one specifically for changing the readonly attribute.

Yes, there is an aria-readonly that you could potentially toggle but it's a property attribute and not a state attribute. It's a fine distinction but in general, state attributes, such as aria-checked or aria-expanded, are expected to change/toggle, usually based on user interaction, and thus their state change is automatically announced by the screen reader without you having to do any extra coding (other than actually changing the value of the attribute).

Property attributes are generally set once and don't change so the screen reader will not announce changes to these attributes. For example, aria-label or aria-multiline or aria-readonly. There's nothing that prevents you from changing the value of these attributes, and it's perfectly valid to do so, but the change will not be announced.

In your case, it doesn't sound like you're changing the value of any ARIA attributes. You're using the built in readonly attribute on the <input>, right?

When the user makes the change, do you visually notify the user that all the fields are editable now? Or do you rely on the appearance of the input field changing from readonly to editable to be the indicator?

If you display a visible text message that says something like "all fields are editable now", then you can make that text message an aria-live region. If you don't display a message like that, then you can create a visibly hidden message just for screen reader users. From a UX perspective, it'd be better for everyone to know about the change, but without seeing your application, perhaps you're already notifying the users in some way.

Assuming you have a text message that you display to users, then you could have something like this:

<div aria-live="polite">
</div>

Then when you inject text into the container, it'll automatically be announced by screen readers.

<div aria-live="polite">
  all fields are editable now
</div>

If you don't want that message to be visible, you can use a "sr-only" type class. There's nothing special about the name of that class. It's just a common name to use. See What is sr-only in Bootstrap 3?

<div aria-live="polite" class="sr-only">
</div>
slugolicious
  • 15,824
  • 2
  • 29
  • 43
  • This is an amazing answer, thank you for taking your time to write this up! Just to be sure I understood, the use of `aria-controls` does not serve any useful purpose for my scenario and can be omitted, right? Visually, the form changes dramatically which is why I really like your suggestion of using an `aria-live` attribute combined with the `sr-only` class for screen readers. Your answer also made me aware of the fact that I should be using `aria-live` for the error message, thank you! – eballeste Nov 11 '22 at 20:24
  • Follow up question, is the fact that the live region is announcing an update enough to tie the awareness of the editable state of the form with the act of clicking on the button? Wouldn't the `polite` value deprioritize the message for screen readers allowing a possible disconnect between the act of clicking and the message? – eballeste Nov 11 '22 at 20:45
  • 1
    `aria-controls` doesn't add much functionality. I only know of one screen reader that tries to do something with it. See https://heydonworks.com/article/aria-controls-is-poop/. And yes, using `aria-live` with error messages is pretty essential. – slugolicious Nov 12 '22 at 02:07
  • 1
    Regarding the followup question, I don't quite follow. If the user tabs to a button with a label like "make form editable" (or hopefully something worded better than that :-)), and then they hear the `aria-live` announcement, that should be enough to tie the announcement with the button click since it was announced after the button was clicked. This also assumes your button has an appropriate label so the user won't be surprised when they click on it. While it is theoretically possible that another screen reader announcement might be queued before your `aria-live` is read, that is a rarity. – slugolicious Nov 12 '22 at 02:12
  • gotcha, makes sense. thank you for sharing your knowledge. – eballeste Nov 12 '22 at 05:16