Semantic markup and accessibility

This section will cover the main info about the semantic meaning of your HTML, CSS, javascript code and "semantic" term in general.

Related links:

• The main book to read - Ben Frain, "Responsive web design with html5 and css3", Глава 4, стр. 91 - 114
• Addition to the book:
  • MDN Web docs Glossary (semantic): https://developer.mozilla.org/en-US/docs/Glossary... You can also find information about semantic tags;
  • HTML5 — обзор, http://fe.it-academy.by/Materials/HTMLCSS_V10/HTM...
  • Контентная модель HTML5, https://html5book.ru/kontentnaya-model-html5/
  • Семантические элементы HTML, https://html5book.ru/html5-semantic-elements/
  • HTML5 Semantic Elements, https://www.w3schools.com/html/html5_semantic_ele...
  • An Overview of HTML5 Semantics, https://codepen.io/mi-lee/post/an-overview-of-htm...
  • Semantic HTML, https://internetingishard.com/html-and-css/semant...
  • HTML5 semantic elements and Webflow: the essential guide, https://webflow.com/blog/html5-semantic-elements-and-webflow-the-essential-guide
  • (can be useful) HTML5 site templates, https://html5up.net/

In order for the web to be accessible to people with disabilities, it is fundamental that different components of web development and interaction work together. Component accessibility is essential; you can’t create accessible web sites if your components are not accessible. As component developers, accessibility has always been a focus for us, and we have been constantly improving it. This section will cover the base steps and technics to keep your resource more accessible to users.

Related links:

• Role attributes
  • The role attribute bridges areas with accessibility issues that can’t be managed with native HTML. It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree. For example, you can tell browsers and assistive technologies that a specific div element acts as a menu, grid, or listbox.
    You can find a complete list of roles in The Roles Model section of the W3C documentation. Also, for instance, can be useful next article https://gaserge.ru/blog/html,css/atribut-role-v-html5.html
• ARIA
  • ARIA in HTML, https://www.w3.org/TR/html-aria/
  • Introduction to ARIA, https://developers.google.com/web/fundamentals/accessibility/semantics-aria/
  • How to Use ARIA Effectively with HTML5, https://www.sitepoint.com/how-to-use-aria-effectively-with-html5/
• Keyboard
  • The W3C WAI-ARIA Authoring Practices document describes the keyboard interactions commonly expected for common types of component.
• Labels
  • Label elements are important because they help identify input elements and they improve mouse handling. Clicking on a label raises the click event for the labeled element. However, label elements can only be used to label “labelable” elements, which includes only a few specific HTML elements (button, input, textarea, select, and a few others). To support labels, custom components have to use a technique such as the one described by Rob Dodson in his How to Label Custom Elements video.
• Tab index
  • Users expect the cursor keys to move the selection to the next/previous item (character, cell, tab, node) within the currently focused component. The tab key should move the focus to the next/previous component on the page. For more details, check Rob Dodson’s Roving TabIndex video or the Roving TabIndex video or the “Roving Tabindex” section on the Keyboard-navigable JavaScript widgets MDN article.
• Focus
  • By default, browsers add a “focus ring” around the element that currently has the keyboard focus. This is important because, without it, users may have a hard time telling which element currently has the focus. This is a basic requirement in the WCAG 2.0 checklist (2.4.7). Because of this, simply turning off the browser’s focus ring is usually not a good idea. To improve your skills, try to pass the Google Web Accessibility course.