button table { margin: 0; } .fa-arrow-left::before {content:"←"} Bad code <button type="button" onclick="window.open('https://example.com/other-page')"> <table> <tbody> <tr> <td> <i class="fa fa-arrow-left" aria-hidden="true"></i> </td> <td align="left">Back</td> </tr> </tbody> </table> </button> Back Issues and how to fix them The HTML isn't valid because the table element isn't allowed as a child of the button element. Based on the content categories listed on MDN, the table element qualifies as flow content and can only be placed inside an element that expects flow content. The button element, on the other hand, expects phrasing content, not flow content. The semantic information of the table doesn't cause any issues because the button's content is presentational See Buttons Role on W3C, Presentational Children. Keep it simple and structure the button element using CSS, such as Flexbox. Instead of using tables to structure the button element, use phrasing content elements, such as span, img, or SVG. Good code <button type="button" onclick="alert('Hello World!')"> Back </button> Resources <button> on MDN <table> on MDN Content categories on MDN Buttons Role on W3C <button> on W3Schools <table> on W3Schools Presentational Children

by Rian Rietveld It's a common pattern to use a logo in the header as a link to the homepage. Fun fact: the alt text of the image inside a link, will be added to the link text. The problem with linking a logo is that it serves 2 purposes: a logo, that tells you which site you are visiting; a link, that leads to the homepage. So add both that info in the alt text. Explain what's on the image and where the link leads to: "Site name logo, to the homepage". Note: Start the alt text with the visible text, then the link will be easier to target for people using voice recognition software. Let's take as example the logo of my home town Leidschendam-Voorburg. In code (simplified): <a href="/"> <img alt="Leidschendam-Voorburg logo, to the homepage" src="logo-lv.svg" /> </a> Generated HTML: VoiceOver in Safari will announce this as: All info is there. There is an advantage of using the alt text instead of an aria-label solution. When the connection is slow, the alt text will show up before the image does and already informs all users of the site name and link destination. It's quite robust. Discussion Do I need the word logo? Isn't that redundant, like the word image or picture? Yes, in this case the fact that this is a logo tells important info. Not only for blind users, but for all screenreader users. If you are visually impaired but not totally blind, you may see the image vaguely. With the addition of the word logo, you also know what the image is. The site name is required, but the logo gives extra context. Isn't this a violation of 2.5.3 Label in Name? No, the visible name is in the alt text, which becomes the accessible name of the link. Adding extra context to the link is common practice. Compare this with the notorious "Read more" link in a card. A common pattern is to use a sr-only CSS class (or equivalent) with additional text: <a href="url">Read more<span class="sr-only"> about cute kitten</span></a> . You see Read more. You hear Read more about cute kitten. In our case: You see the site name and logo; the visual position tells the link destination. You hear the site name, the fact it's a logo and the link destination. The whole visible text should be in the accessible name, but extra information, like the meaning of the image and link destination can be added for context. That way the purpose of the link is explained. Why didn't you use an aria-label? Of course there are other and also valid solutions. By using plain simple HTML I want to honor the first rule of ARIA: If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so. Happy Holidays!

Bad code <button type="button" onclick="window.open('https://example.com/other-page')">Link target description</button> Issues and how to fix them A button opening a link will be unexpected behavior for screen reader users. No matter how it is styled. Links disguised as buttons won’t show up in the link list of a site in assistive technologies. Use links for navigation to other pages or sections, and buttons for actions performed on the current page or within the application. Good code <a href="https://example.com/other-page">Link target description</a> Resources ` on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a) - [`` on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button) - [Buttons vs. Links by Eric Eggert](https://yatil.net/blog/buttons-vs-links)

The good intentions were there but in the HTML and Accessibility world, less is sometimes more. Bad code <label for="textinput">First name</label> <input type="text" id="textinput" aria-label="First name" placeholder="First name" title="First name"> Issues and how to fix them The aria-label, placeholder, and title attributes all provide the same informaton ("First name"), leading to the screenreader reading the same text multiple times. The aria-label is unnecessary since the input is already correctly labeled by the <label> element. <label> elements should be preferred to aria-label since they are also visible to sighted users. The title attribute is not needed here, as the label and placeholder already convey the necessary information. Using title in this context adds unnecessary complexity. The placeholder text should provide a hint / example to the user what kind of input is expected, it should not act as a label or contain the same content. Good code <label for="textinput">First name</label> <input type="text" id="textinput"> Resources <label> on MDN aria-label on MDN placeholder on MDN title on MDN