{"id":884,"date":"2023-05-08T12:48:17","date_gmt":"2023-05-08T12:48:17","guid":{"rendered":"https:\/\/html5accessibility.com\/stuff\/?p=884"},"modified":"2023-05-08T15:48:41","modified_gmt":"2023-05-08T15:48:41","slug":"shatgpt","status":"publish","type":"post","link":"https:\/\/html5accessibility.com\/stuff\/2023\/05\/08\/shatgpt\/","title":{"rendered":"ShatGPT"},"content":{"rendered":"

\"In<\/p>\n

Failing at the first hurdle<\/h2>\n

I am concerned. Not about Large Language Models (LLM)s doing me out of a job, but about the people who make money out of them not making their User Interfaces (UI)s accessible.<\/p>\n

Not about their ethical use, though there is\u00a0plenty to be concerned about<\/a>,\u00a0 but about the accessibility and usability of their UI’s.<\/p>\n

The biases inherent within LLM’s is writ large upon the UI’s provided to make use of them.<\/p>\n

Closed AI<\/h2>\n

A cursory review of the ChatGPT UI shows it is broken for many people:<\/p>\n

\"The<\/p>\n

Keyboard operability desert<\/h3>\n

The Chat history is largely not navigable or operable using the keyboard as the links are not focusable. For example, the Custom Listbox Example\u00a0 <\/em>“link” is an <a><\/code> element without a href<\/code> or tabindex<\/code>, thus it cannot be navigated to or operated using a keyboard.<\/p>\n

<a class=\"flex py-3 ...\">\r\n<svg stroke=\"currentColor\" fill=\"none\" stroke-width=\"2\" ...>\r\n...<\/svg>\r\n<div class=\"flex-1...\">Custom Listbox Example\r\n...<\/div>\r\n<\/a><\/pre>\n
Feast of unlabelled buttons<\/h3>\n
If you have good eyesight you can sort of<\/em> work out what the various buttons in the UI do, but if you rely upon the accessible names of controls to understand what they do, you are out of luck.<\/p>\n
\"The<\/p>\n
For example, the JAWS screen reader<\/a> announces “unlabelled button 1, unlabelled button 2, unlabelled button 3”<\/p>\n
Likewise if you have low vision: The buttons are small light grey icons with no text label…<\/p>\n
\"The<\/p>\n
Foreground: # ACACBE
\nBackground: # F7F7F8
\nThe contrast ratio is: 2.1:1
\n1.4.11 Non-text Contrast (AA)
\nFail for UI components and graphical objects<\/strong><\/p><\/blockquote>\n
Not for some of you<\/h3>\n
The ChatGPT version selection control has an information panel about each versions Reasoning\/Speed and Conciseness. Useful information, tough luck if you are a screen reader user, you are probably not even aware the information is there.<\/p>\n
\"With<\/p>\n
I could go on, there are plenty of issues, but you get the idea. My aim here is not to provide free advice<\/strong> on how a multi billion dollar company<\/a> can make its products more usable and accessible for people with disabilities. OpenAI has lots of smart people and the resources to put accessibility first, it does not auger well that it hasn’t.<\/p>\n
I could suggest they use their own product to suggest improvements but…<\/p>\n
ChatGPT may produce inaccurate information about people, places, or facts.<\/p><\/blockquote>\n
I asked ChatGPT4<\/p>\n
How do is make the following code more accessible?<\/p>\n
<a> \r\n<svg ...> \r\n<\/svg> \r\n<div>Custom Listbox Example <\/div> \r\n<\/a><\/pre>\n<\/blockquote>\n
It answered: (the strike-outs are mine)<\/p>\n
To make the given code more accessible, you should provide descriptive attributes, such as aria-label<\/code>, role<\/code>, and tabindex<\/code><\/del>. Also, it’s better to use a <button><\/code> element instead of an <a><\/code> element since the content is not a typical link.<\/p>\n
<button aria-label=\"Custom Listbox Example\"<\/del> \r\nrole=\"button\"<\/del> tabindex=\"0\"<\/del>>\r\n<svg aria-hidden=\"true\" focusable=\"false\" ...>\r\n<\/svg>\r\n<div>Custom Listbox Example<\/div>\r\n<\/button><\/pre>\n
Here’s a breakdown of the changes:<\/p>\n
    \n
  1. Replace the <a><\/code> element with a <button><\/code> element. Buttons are more appropriate for actions that don’t navigate to a new URL. They also have built-in keyboard support, making them more accessible for keyboard users.<\/li>\n
  2. Add an aria-label<\/code> attribute to the <button><\/code> element to provide a descriptive label for screen readers. This helps users understand the purpose of the button.<\/del><\/li>\n
  3. Add a role<\/code> attribute with the value “button” to indicate that the element is a button. While this is not strictly necessary for a <button><\/code> element (since its role is already implicitly “button”), it’s a good practice to include it for clarity.<\/del><\/li>\n
  4. Add a tabindex<\/code> attribute with the value “0” to ensure that the button is part of the tab order, making it reachable for keyboard users.<\/del><\/li>\n
  5. Add the aria-hidden=\"true\"<\/code> attribute to the <svg><\/code> element to indicate that it should be hidden from screen readers, as it’s a decorative element and its presence might be confusing.<\/li>\n
  6. Add the focusable=\"false\"<\/code> attribute to the <svg><\/code> element to prevent it from receiving keyboard focus. This ensures that keyboard users won’t accidentally focus on the SVG instead of the button.<\/li>\n<\/ol>\n
    By making these changes, you’ll create a more accessible experience for users who rely on screen readers or keyboard navigation.<\/p><\/blockquote>\n
    The last 2 are questionable. The following I consider as W3Schools<\/em> accessibility, expect the Accessibility Industry Grifters (AIGs) to be pushing this sort of advice as gospel<\/p>\n
    Add an aria-label<\/code> attribute to the <button><\/code> element to provide a descriptive label for screen readers. This helps users understand the purpose of the button.<\/p><\/blockquote>\n
    Not needed as it is labelled by child text<\/p>\n
    Add a role<\/code> attribute with the value “button” to indicate that the element is a button. While this is not strictly necessary for a <button><\/code> element (since its role is already implicitly “button”), it’s a good practice to include it for clarity.<\/p><\/blockquote>\n
    Not needed as the it is exposed as a button<\/code> already, since it is a button<\/code><\/strong><\/p>\n
    It’s not even a good practice.\u00a0<\/em>This practice is specifically called out\u00a0\u00a0in the relevant W3C specification as something to avoid:<\/p>\n
    The following example illustrates a\u00a0button<\/a><\/code>\u00a0element which has also been provided an explicit\u00a0role=button<\/code>. Specifying this role is unnecessary, as a “button” element is already exposed with an implicit\u00a0button<\/code> role. In practice this particular instance of redundancy will likely not have unforeseen side effects, other than unnecessarily making the markup more verbose, and incorrectly signalling to other authors that this practice is useful.<\/p>\n
    source:<\/strong> ARIA in HTML – 3.2 Avoid specifying redundant roles<\/a><\/p><\/blockquote>\n
    Add a tabindex<\/code> attribute with the value “0” to ensure that the button is part of the tab order, making it reachable for keyboard users.<\/p><\/blockquote>\n
    Not needed as a button<\/code> is focusable by default<\/p>\n