By the end of the lesson, you can say why a native HTML element is better than a div upgraded with ARIA, you can go through a page with the keyboard and evaluate the focus, you can explain what a screen reader sees, and you can interpret the result of an automatic accessibility check, together with its limitations.
Why is "it looks good" not enough?
Semantic HTML (3.2) describes the role of the elements of the page, not merely their look. For a person navigating with the keyboard and using a screen reader, it is especially important that headings, links, buttons, forms, and feedback form an interpretable structure. If a clickable div looks just like a button, it makes no difference to the eye, but it does to assistive technology.
Semantics: what does an element mean?
Let us look at two solutions for a clickable element. One is a div that got a click handler, the other is a real button or a element. On the screen both can be a blue, rounded rectangle. For the browser and assistive technology, however, they differ: a link navigates to another place or resource; a button starts an action, for example submits a form.
Semantic HTML means that we choose the element that suits the meaning of the document. header, nav, main, article, aside, and footer provide orientation points (landmarks). The headings h1–h6 express a hierarchy. p is a paragraph, ul and ol a list, table tabular data, label the name of a form field.
This structure is useful on several channels: the screen reader user can jump by headings; the search engine understands better what the main content is (9.5); and the code is more readable for the browser and the later maintainer too.
flowchart LR
H[HTML semantics] --> A[Accessibility tree]
A --> R[Screen reader]
H --> B[Keyboard focus]
B --> U[User action]
Headings: not font sizes
A common mistake is that a caption meant as a title is just a larger, bold div or span. This makes it look like a heading visually, but it is not a heading in the document. It is the same mistake to choose h1–h6 elements only for their size. A page usually has a main heading (h1), whose topics are structured by h2s, and their parts by h3s. Imagine the page as a table of contents: if the line of thought is not understandable from it, the heading structure needs fixing.
The keyboard is not a secondary input mode
Many people use the web with a mouse, but not everyone. The Tab key typically moves to the next focusable element, Shift+Tab backward. With Enter a link or button can be activated, Space often operates a button, checkbox, or switch. The role of the arrow keys depends on the control type (radio group, menu).
The focus order should follow the logical order of the content. The look can be rearranged with CSS, but the order of the HTML still determines how the keyboard and the screen reader move. Because of a long, repeated menu it is worth providing a "Skip to main content" link, which is usually hidden but becomes visible when it receives focus.
How does a screen reader "see"?
A screen reader is an assistive technology that conveys the digital interface with speech or on a Braille display. It does not interpret the pixels of the screen but the accessibility tree made available by the browser: this includes the element's role, name, state, and value.
With a good button the user may hear "Open cart, button". With a faulty div, only "Open cart", or not even that. With an input field the label connects the field with its question: "Email address, edit field". A placeholder shown only as a placeholder does not replace the label: it disappears while typing, its contrast can be weak, and it does not give a reliable name in every situation.
A screen reader user does not necessarily read the page linearly from start to end: they can list the headings, the links, the form fields, or the landmarks. That is why many "More" and "Click here" links are confusing: in a list only identical, meaningless labels appear one after another. The text of a link should state its purpose on its own: "Open the admission deadlines".
Forms and errors
In forms, besides the visible label, the connection should be expressed in a machine-readable way as well: the for attribute of the label points to the id of the field. This way clicking the label activates the field too, and assistive technology names it correctly. On error do not use only the color red: the error message should say which field it concerns, what the problem is, and if possible how to fix it. After submission it is worth directing the focus to the first faulty field or to the summary of errors.
ARIA: an important tool, but not the first choice
ARIA (Accessible Rich Internet Applications) attributes can give roles, names, and states to complex controls for which there is no native HTML equivalent. For example, in a self-made collapsible panel aria-expanded can signal whether the content is open; a button made of an icon can get a meaningful name with aria-label.
The basic principle: native HTML first. According to the W3C's ARIA guide, "no ARIA is better than bad ARIA", because ARIA roles do not give the browser keyboard behavior or styling: if a div gets role="button", we have to write the keyboard handling, the focus, and the disabled state, and the role is a "promise" that must be kept. ARIA does not make an element work, it only communicates information about it. The button element already knows all of this.
What does the automatic check say? A tried example
We made two versions of a course page: a deliberately faulty ("bad") page and a fixed ("good") page. On the bad page there is no lang, title, main, and alt, the text is pale gray (#aaa, 2.32:1), the "button" is a div, the text of the link is "Kattints ide" ("Click here"), and the input field got only a placeholder. The good page fixes these (lang, title, main, alt, button, label, #444 text).
We ran both with the Lighthouse automatic checking tool (version 13.5.0, in a Chrome 154 browser, in a simulated mobile environment). The accessibility score:
Page
Accessibility (0–100)
Errors reported by Lighthouse
Bad
52
no lang, no title, the image has no alt, no main region, insufficient contrast
Good
100
–
What is important, however, is what the tool did not report on the bad page:
the div that we meant as a clickable "button" (the "button-name" audit is not applicable, because there is no button element);
the meaningless text of the "Click here" link (the link audit checks whether it has a name, not whether it is meaningful);
the field "labeled" with placeholder text, which the tool let through;
whether an h3 comes before the h1 (the heading-order audit reported no error).
The automatic checker is therefore a useful pre-filter, but does not grade: a score of 100 does not mean a flawless page, and a 52 does not reveal all the problems either. The tools cannot judge whether an alternative text is meaningful or whether a flow is understandable. For the full picture a manual test (keyboard, screen reader) is also needed.
Worked example: the login window of Kurzuspont
A "Log in" button opens a dialog. With a mouse this seems simple, but with a keyboard more questions arise: when it opens, the focus lands on a sensible first element of the window (the title or the email field); with Tab the focus stays inside the window; it can be closed with Esc if this does not cause data loss; on closing, the focus returns to the button that opened it. The window must have a clear name. Good focus management makes the interface more predictable for both mouse and keyboard.
A simple checking routine
Many errors can be discovered already during development without special tools. Put the mouse aside, reload the page, and try to complete the main task using only Tab, Shift+Tab, Enter, Space, and Esc. Is the focus visible at every moment? Do we reach every essential control? Do we get stuck in an opened component? It is also worth looking at the accessibility tree with the browser's developer tools: it often immediately turns out if an icon button has no name, or a caption that looks like a heading is in fact only formatted text. This does not replace a test with a screen reader, but it is quick feedback.
Common misconceptions
Statement
Clarification
"If it is clickable, it is accessible."
Being clickable does not mean it is keyboard-reachable, focusable, and announced correctly as a control.
"tabindex puts the order right."
Positive tabindex values often give an unpredictable order; the correct HTML order is the basis.
"The placeholder is the label of the field."
It is not: it can be short help, but it does not replace a permanent, programmatically identifiable label.
"Everything needs ARIA."
Excessive or bad ARIA makes things worse; native HTML solves many tasks.
"A 100-point Lighthouse result = accessible."
The tool finds only the errors that can be checked by machine.
In brief
A semantic element communicates its role to assistive technology, not just its look.
Keyboard use is fundamental: visible focus, logical order, a skip link.
A screen reader reads the accessibility tree (role, name, state, value).
ARIA only fills the lack of native HTML; bad ARIA is worse than no ARIA.
An automatic checker is useful but incomplete: a manual test is needed too.
Review questions
What is the difference between a button and a div role="button"?
What happens if we remove the focus outline?
Why does the placeholder not replace the label element?
What did Lighthouse report and what did it not report on the faulty course page?
Semantics, keyboard, and screen reader
Objectives
By the end of the lesson, you can say why a native HTML element is better than a
divupgraded with ARIA, you can go through a page with the keyboard and evaluate the focus, you can explain what a screen reader sees, and you can interpret the result of an automatic accessibility check, together with its limitations.Why is "it looks good" not enough?
Semantic HTML (3.2) describes the role of the elements of the page, not merely their look. For a person navigating with the keyboard and using a screen reader, it is especially important that headings, links, buttons, forms, and feedback form an interpretable structure. If a clickable
divlooks just like a button, it makes no difference to the eye, but it does to assistive technology.Semantics: what does an element mean?
Let us look at two solutions for a clickable element. One is a
divthat got a click handler, the other is a realbuttonoraelement. On the screen both can be a blue, rounded rectangle. For the browser and assistive technology, however, they differ: a link navigates to another place or resource; a button starts an action, for example submits a form.Semantic HTML means that we choose the element that suits the meaning of the document.
header,nav,main,article,aside, andfooterprovide orientation points (landmarks). The headingsh1–h6express a hierarchy.pis a paragraph,ulandola list,tabletabular data,labelthe name of a form field.This structure is useful on several channels: the screen reader user can jump by headings; the search engine understands better what the main content is (9.5); and the code is more readable for the browser and the later maintainer too.
flowchart LR H[HTML semantics] --> A[Accessibility tree] A --> R[Screen reader] H --> B[Keyboard focus] B --> U[User action]Headings: not font sizes
A common mistake is that a caption meant as a title is just a larger, bold
divorspan. This makes it look like a heading visually, but it is not a heading in the document. It is the same mistake to chooseh1–h6elements only for their size. A page usually has a main heading (h1), whose topics are structured byh2s, and their parts byh3s. Imagine the page as a table of contents: if the line of thought is not understandable from it, the heading structure needs fixing.The keyboard is not a secondary input mode
Many people use the web with a mouse, but not everyone. The Tab key typically moves to the next focusable element, Shift+Tab backward. With Enter a link or button can be activated, Space often operates a button, checkbox, or switch. The role of the arrow keys depends on the control type (radio group, menu).
The focus order should follow the logical order of the content. The look can be rearranged with CSS, but the order of the HTML still determines how the keyboard and the screen reader move. Because of a long, repeated menu it is worth providing a "Skip to main content" link, which is usually hidden but becomes visible when it receives focus.
How does a screen reader "see"?
A screen reader is an assistive technology that conveys the digital interface with speech or on a Braille display. It does not interpret the pixels of the screen but the accessibility tree made available by the browser: this includes the element's role, name, state, and value.
With a good button the user may hear "Open cart, button". With a faulty
div, only "Open cart", or not even that. With an input field thelabelconnects the field with its question: "Email address, edit field". Aplaceholdershown only as a placeholder does not replace the label: it disappears while typing, its contrast can be weak, and it does not give a reliable name in every situation.A screen reader user does not necessarily read the page linearly from start to end: they can list the headings, the links, the form fields, or the landmarks. That is why many "More" and "Click here" links are confusing: in a list only identical, meaningless labels appear one after another. The text of a link should state its purpose on its own: "Open the admission deadlines".
Forms and errors
In forms, besides the visible label, the connection should be expressed in a machine-readable way as well: the
forattribute of thelabelpoints to theidof the field. This way clicking the label activates the field too, and assistive technology names it correctly. On error do not use only the color red: the error message should say which field it concerns, what the problem is, and if possible how to fix it. After submission it is worth directing the focus to the first faulty field or to the summary of errors.ARIA: an important tool, but not the first choice
ARIA (Accessible Rich Internet Applications) attributes can give roles, names, and states to complex controls for which there is no native HTML equivalent. For example, in a self-made collapsible panel
aria-expandedcan signal whether the content is open; a button made of an icon can get a meaningful name witharia-label.The basic principle: native HTML first. According to the W3C's ARIA guide, "no ARIA is better than bad ARIA", because ARIA roles do not give the browser keyboard behavior or styling: if a
divgetsrole="button", we have to write the keyboard handling, the focus, and the disabled state, and the role is a "promise" that must be kept. ARIA does not make an element work, it only communicates information about it. Thebuttonelement already knows all of this.What does the automatic check say? A tried example
We made two versions of a course page: a deliberately faulty ("bad") page and a fixed ("good") page. On the bad page there is no
lang,title,main, andalt, the text is pale gray (#aaa, 2.32:1), the "button" is adiv, the text of the link is "Kattints ide" ("Click here"), and the input field got only aplaceholder. The good page fixes these (lang,title,main,alt,button,label,#444text).We ran both with the Lighthouse automatic checking tool (version 13.5.0, in a Chrome 154 browser, in a simulated mobile environment). The accessibility score:
lang, notitle, the image has noalt, nomainregion, insufficient contrastWhat is important, however, is what the tool did not report on the bad page:
divthat we meant as a clickable "button" (the "button-name" audit is not applicable, because there is nobuttonelement);h3comes before theh1(the heading-order audit reported no error).The automatic checker is therefore a useful pre-filter, but does not grade: a score of
100does not mean a flawless page, and a52does not reveal all the problems either. The tools cannot judge whether an alternative text is meaningful or whether a flow is understandable. For the full picture a manual test (keyboard, screen reader) is also needed.Worked example: the login window of Kurzuspont
A "Log in" button opens a dialog. With a mouse this seems simple, but with a keyboard more questions arise: when it opens, the focus lands on a sensible first element of the window (the title or the email field); with Tab the focus stays inside the window; it can be closed with Esc if this does not cause data loss; on closing, the focus returns to the button that opened it. The window must have a clear name. Good focus management makes the interface more predictable for both mouse and keyboard.
A simple checking routine
Many errors can be discovered already during development without special tools. Put the mouse aside, reload the page, and try to complete the main task using only Tab, Shift+Tab, Enter, Space, and Esc. Is the focus visible at every moment? Do we reach every essential control? Do we get stuck in an opened component? It is also worth looking at the accessibility tree with the browser's developer tools: it often immediately turns out if an icon button has no name, or a caption that looks like a heading is in fact only formatted text. This does not replace a test with a screen reader, but it is quick feedback.
Common misconceptions
tabindexputs the order right."tabindexvalues often give an unpredictable order; the correct HTML order is the basis.In brief
Review questions
buttonand adiv role="button"?placeholdernot replace thelabelelement?Learning resources