I’m sure I’m not the only one who has been blown away by OpenAI’s ChatGPT application. It reminds me of trying to make my Commodore 64 speak typed text with the Covox VoiceMaster (yes, that dates me a bit). ChatGPT makes me stop in wonder, thinking about its abilities and how it could help humanity.

I hope we use it for good. I can’t help thinking about how Artificial Intelligence (AI) could play more of a role in digital accessibility. Will it replace developers? Will it replace accessibility consultants? Will it replace automated testing applications as we know them today? Will accessibility overlay companies go wild with it?

ChatGPT’s current experience isn’t super accessible

Unfortunately, at the time of this writing, the base application for fiddling around with the free version of ChatGPT is not accessible. Mainly, the form field (textarea) you type your question into, as well as the button which submits the form, both lack an accessible label.

Let’s see if ChatGPT can fix its own accessibility issues. In this post you will see the back-and-forth between me and ChatGPT about its accessibility issue and witness it trying to fix itself. I will reduce some code fragments to make reading easier.

This article is not meant to shame OpenAI (who created ChatGPT) about their accessibility woes. The experiment sounded fun and who knows, maybe they’ll hear about this post and fix things!

Joe Watkins and ChatGPT conversation

Joe: Hi ChatGPT, did you know that the textarea I’m typing this question into is not accessible?

ChatGPT: I’m sorry, as a language model AI I don’t have the ability to see the context or physical environment of the text area. However, if you’re referring to accessibility in the context of web development, it refers to the practice of making websites usable for people with disabilities, including visually impaired users, who may use assistive technologies like screen readers. Improving the accessibility of a textarea may involve adding proper ARIA labels, providing keyboard-based navigation, and ensuring that it can be easily resized and read by assistive technologies.

Joe: Here is the code I am referring to:

<textarea tabindex="0" placeholder="" class="..." style="...">
<!-- ... -->
</textarea>
<button class="...">
<!-- svg icon -->
</button>

ChatGPT: The code you posted is for a <textarea> HTML element with associated styles and a button element. The tabindex attribute sets the order in which elements receive focus when the user presses the “Tab” key. The data-id attribute is a custom attribute that could be used for various purposes, such as identifying the element for scripting.

The styles set the dimensions and appearance of the text area, such as the maximum height, the height, the overflow behavior, and the background color. It also specifies the padding and the border. The button element appears to be an icon, likely used to clear the contents of the text area.

In terms of accessibility, the code appears to have some issues:

  1. The tabindex attribute is set to “0”, which could cause unexpected focus order.
  2. The placeholder attribute is empty, which may not provide sufficient information to users on what they should enter in the text area.
  3. The aria-label attribute is missing, which could cause issues for users of assistive technologies like screen readers.
  4. Improving accessibility would require addressing these issues, such as by adding a descriptive aria-label, providing a meaningful placeholder, and ensuring that the tabindex attribute is used properly.

Joe: Ok, I think a good aria-label for this textarea would be “Ask ChatGPT a question”. Can you update the code to be more accessible?

ChatGPT: Sure, here’s an updated version of the code with a descriptive aria-label:

<textarea aria-label="Ask ChatGPT a question" tabindex="0" class="..." style="...">
<!-- ... -->
</textarea>
<button class="...">
<!-- svg icon -->
</button>

With this change, screen readers can announce the purpose of the text area to users, making it easier for them to understand how to use it.

Joe: What about sighted users who are not using a screen reader? Will they see the new label?

ChatGPT: No, the aria-label attribute is not visible to users who are not using a screen reader. The aria-label attribute provides additional information for assistive technologies, but it is not displayed on the screen.

If you also want the label to be visible to users without assistive technologies, you can add a visible label or placeholder text. Here’s an updated version of the code with both a visible label and the aria-label attribute:

<label for="questionTextArea">Ask ChatGPT a question:</label>
<textarea id="questionTextArea" aria-label="Ask ChatGPT a question" tabindex="0" class="..." style="...">
<!-- ... -->
</textarea>
<button class="...">
<!-- svg icon -->
</button>

This way, both users with and without assistive technologies can see the label and understand the purpose of the text area.

Joe: Do we need both aria-label and a label element? And if not why?

ChatGPT: In general, it’s recommended to use both a visible label and an aria-label for the textarea for the best accessibility and usability for all users.

A visible label is essential for users who are not using assistive technologies, as it provides a clear and explicit indication of what the textarea is for. On the other hand, the aria-label attribute provides a label for assistive technologies, such as screen readers, for users who are unable to see the visible label.

Having both a visible label and an aria-label provides the most comprehensive accessibility solution, ensuring that all users, regardless of their abilities, can understand the purpose of the textarea.

If you only use an aria-label, users who are not using assistive technologies may not know what the textarea is for, which can be confusing. On the other hand, if you only use a visible label, users with visual impairments who use screen readers may not be able to understand the purpose of the textarea, as the screen reader will not announce the visible label.

Joe: A screen reader is capable of announcing the visual label because of the programmatic association of the label to the textarea by use of the for attribute on the label element.

ChatGPT: Yes, you’re correct! I apologize for the oversight.

Associating a visual label with a form control, such as a textarea, through the for attribute on the label element and the id attribute on the form control allows screen readers to announce the visual label when the form control receives focus.

In this case, using only a visible label with a for and id attribute is sufficient for making the textarea accessible. An aria-label is not strictly necessary, although it is still a good practice to include it as an additional accessibility feature.

Here’s an updated version of the code with just a visible label:

<label for="questionTextArea">Ask ChatGPT a question:</label>
<textarea id="questionTextArea" tabindex="0" data-id="root" rows="1" placeholder="" class="..." style="...">
<!-- ... -->
</textarea>
<button class="...">
<!-- svg icon -->
</button>

Joe: You had mentioned a tabindex not being needed and are you sure the button is accessible?

ChatGPT: I apologize for any confusion. Tabindex is not strictly necessary for the textarea, as it is a form control that is typically keyboard-focusable by default, but it won’t hurt to include it.

Regarding the button, its accessibility is less certain as it currently stands. Screen readers announce the text of the button, and not just the shape of the svg. A <button> element should have text or an accessible name provided through an aria-label or aria-labelledby attribute to indicate its purpose to assistive technology users.

Here’s an updated version of the code with an aria-label for the button:

<label for="questionTextArea">Ask ChatGPT a question:</label>
<textarea id="questionTextArea" tabindex="0" data-id="root" rows="1" placeholder="" class="..." style="...">
<!-- ... -->
</textarea>
<button aria-label="Submit question" class="...">
<!-- svg icon -->
</button>

Joe: Why do you like to use so much ARIA? Don’t you know the first rule of ARIA?

ChatGPT: As an AI language model, I don’t have personal preferences or opinions. I use ARIA to enhance the accessibility of web content for users with disabilities, particularly users who rely on assistive technologies like screen readers. ARIA provides a way to add additional semantics and attributes to HTML elements, allowing assistive technologies to better convey the meaning and purpose of elements to their users.

Regarding the “first rule of ARIA”, it’s often stated that the first rule of ARIA is to use native HTML elements whenever possible, and only use ARIA when there is no native HTML equivalent that meets the needs of the particular use case. This is because native HTML elements are easier to understand and implement, and have better accessibility support built-in, as well as better performance. However, when a semantic or functional gap exists in HTML, ARIA can provide the necessary information to ensure that the web content is accessible to all users.

Joe: Is there an alternative to using ARIA for the button’s label?

ChatGPT: Yes, the button in the code you provided could use a visually-readable text label in place of an ARIA label. This could be done by adding text content within the button element, for example:

<button class="...">
<span class="sr-only">Submit question</span>
<!-- svg icon -->
</button>

Joe: A class of sr-only on the nested button text? Why?

ChatGPT: The sr-only class is used to visually hide the text label of the button while still making it available to screen readers. This is useful in cases where the visual appearance of the button is represented by an icon and the text label is redundant for sighted users. Screen reader users will still be able to access the text label, ensuring that the button is properly described and its purpose is clear. This allows for a more visually concise design while still providing accessibility.

Joe: Cool! Can you write that sr-only CSS for me?

ChatGPT: Certainly, here’s the CSS code for the sr-only class:

.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}

Joe: Ok, can you provide the final HTML and CSS for your new textarea?

ChatGPT: Sure, here’s the final HTML and CSS code for an accessible textarea:

<label for="questionTextArea">Ask ChatGPT a question:</label>
<textarea id="questionTextArea" aria-describedby="submit-button" tabindex="0" class="..." style="...">
<!-- ... -->
</textarea>
<button id="submit-button" class="...">
<span class="sr-only">Submit question</span>
<!-- svg icon -->
</button>
.sr-only {
position: absolute;
...
}

Joe: I noticed you added aria-describedby to the textarea. What will be announced by the screen reader when the text area is focused? Will that make sense?

ChatGPT: The aria-describedby attribute refers to the ID of an element that provides a description or additional information about the textarea. When the textarea is focused, a screen reader will announce the content of the element with the matching ID.

In this case, it will make sense if the ID refers to a text or element that provides additional information or guidance on how to interact with the textarea, such as the format to enter data, character limits, or other input requirements. The description will be helpful for users who use screen readers to understand the purpose and behavior of the textarea.

Joe: I don’t think we need aria-describedby. I also don’t think we need a tabindex on the textarea, please remove that. Please provide me with an updated HTML and CSS.

ChatGPT: Here is the full HTML and CSS code:

<label for="questionTextArea">Ask ChatGPT a question:</label>
<textarea id="questionTextArea" class="..." style="...">
<!-- ... -->
</textarea>
<button class="...">
<span class="sr-only">Submit question</span>
<!-- svg icon -->
</button>
.sr-only {
position: absolute;
...
}

Joe: Thank you. What do you think Joe Watkins would think of this accessible code?

ChatGPT: As an AI language model, I don’t have personal opinions or thoughts. However, Joe Watkins is a well-respected figure in the accessibility community, and I imagine he would appreciate the effort put into making this textarea more accessible, including the use of a label and a nested button text, as well as the attention paid to making the textarea easy to interact with and understand for users with disabilities. Overall, I believe that the code meets a good level of accessibility standards.

[end chat]

Well, did it work?

I must say, I really enjoyed ChatGPT’s response to my last question – it really tried to butter me up!

In the end, the service was able to come up with an accessible solution to its own accessibility barriers.

It fixed the missing label on both the textarea and the submit button. It did take some coaching. Its initial response was more accessible than what we began with, but not perfect.

We worked through some options that included ARIA and were technically better, but not really needed. Other than coaching ChatGPT away from ARIA overuse and its confusion around the `sr-only` text being visual, I feel it did work.

I was able to audit the code and get new code without writing a bit of it. This took less than five minutes.

ChatGPT had the vibe of someone who does understand their stuff but it still needs a human to carry it over the line – which makes sense at this stage. One could imagine technology like this being a part of more productive and accessible development/testing processes.

I enjoyed how ChatGPT explained its code decisions and that it read back to me in text why it did certain things. This is good for learning. I did not expect things to be perfect, but they ended up better than how they started.

What do you think? Is ChatGPT just another fad? Are you resistant because it scares you? Do you think this type of technology could help our industry? Let’s see what happens.