[ { "role": "user", "content": "from%20an%20accessibility%20perspective%2C%20when%20a%20screen%20reader%20user%20is%20interacting%20with%20a%20tablist%20component%2C%20should%20the%20various%20tabs%20in%20the%20tablist%20also%20be%20announced%20as%20links%3F" }, { "role": "assistant", "content": "No \u2014 tabs in a `tablist` component *should not* be announced as links by screen readers if they're implemented correctly using ARIA and/or semantic HTML. They should be announced as \u201ctabs,\u201d with state information (e.g. \u201cselected\u201d or \u201cnot selected\u201d), and their position in the set (e.g. \u201ctab 2 of 4\u201d). Here\u2019s why, per accepted accessibility standards:\n\n---\n\n## What ARIA / WCAG Say\n\n- **Role definitions**: The ARIA spec defines specific roles for tabbed interfaces. A container wrapping tabs should have role `tablist`, and each tab should have role `tab`. The content sections controlled by tabs should have role `tabpanel`. This explicitly distinguishes them from links. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tab_role?utm_source=openai))\n\n- **Tab behaviour & semantics**: The `role=\"tab\"` signals to assistive technologies that this element behaves as a tab\u2014it activates or switches content panels\u2014not that it navigates to a different resource like a link would. Thus the screen reader announces it as a tab, not a link. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tab_role?utm_source=openai))\n\n- **Unsupported use of interactive children inside tablist**: Tablist should not contain \u201cforbidden interactive children such as links or buttons\u201d unless they also have the `role=\"tab\"` role explicitly. This avoids confusion where, for example, a link inside a tablist might be mistaken for a tab itself. ([knowledge.evinced.com](https://knowledge.evinced.com/components/tablist/?utm_source=openai))\n\n---\n\n## What Users Will Hear with a Proper Tab Implementation\n\nIf tabs are implemented correctly:\n\n- The user will hear something like: **\u201cSettings, tab, 2 of 4, selected\u201d**.\n- If a tab is not selected: **\u201cProfile, tab, 3 of 4\u201d**.\n- Pressing arrow keys moves focus between tabs. Enter or Space activates one. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tab_role?utm_source=openai))\n\nThey **should not** hear \u201clink\u201d in these descriptions, because link implies navigation to another resource (or another page), which is semantically very different.\n\n---\n\n## What Happens When Tabs Are Mis-Implemented\n\nIf you use an `` tag (link) inside the tablist without overriding its semantics, or fail to apply `role=\"tab\"`, then:\n\n- The screen reader will likely announce it as a link (e.g. \u201clink: Profile\u201d).\n- The user might expect navigation to a different document or page, which can cause confusion.\n- Keyboard behavior might also seem inconsistent: links are activated differently than tabs, which can break expectations and accessibility. \n\nEven if you wrap the tab inside an `` tag purely to mimic semantics, you should **still** apply `role=\"tab\"` (or use a `