Die Verknüpfung von Beschriftungen mit den zugeordneten Eingabefeldern stellt sicher, dass der Aufbau einer Seite unabhängig von der Präsentation festgelegt und zugänglich ist:

• Der Screenreader liest die Beschriftungen vor, wenn der Benutzer durch die Formularelemente wandert.

• Ein Vorteil der Nutzung nativer label-Elemente: Mausnutzer können durch einen Klick auf das Label den Fokus auf das zugeordnete Formularelement setzen.

Die Festlegung des Eingabezwecks erlaubt es neuartigen Hilfsmitteln, bei Formularfeldern, welche sich auf Daten des Nutzers beziehen, zusätzliche Informationen anzuzeigen, und zwar unabhängig vom der jeweils gewählten Beschriftung des Feldes und unabhängig von der natürlichen Sprache des Angebots.

Zusätzliche Informationen können etwa Bilder bzw. Icons sein, die über ein Browser-Plugin oder eine externe assistive Technologie bereitgestellt werden und über bzw. vor dem jeweiligen Eingabefeld angezeigt werden, etwa wenn Nutzer eine bestimmte Tastenkombination drücken. Für Menschen, die Schwierigkeiten mit dem Lesen haben oder bevorzugt über Bilder kommunizieren, erleichtert dies eine Identifizierung von nutzerbezogenen Feldern in Formularen.

Darüber hinaus bietet autocomplete Eingabevorschläge für das Feld, welche Nutzer einfach übernehmen können. Das erleichtert die Texteingabe.

Für Tastaturnutzende ist es wichtig, zu sehen, wo sich der Tastaturfokus gerade befindet, welcher Link also ausgelöst wird, wenn er sie die Enter-Taste drücken.

Viele Webseiten erleichtern Mausnutzenden die Bedienung, indem sie darauf reagieren, dass der Mauszeiger sich über einem Link befindet. Dann ändert sich zum Beispiel die Text- oder Hintergrundfarbe oder der Linktext wird unterstrichen. Diese Unterstützung soll auch für Tastaturnutzende funktionieren. Webseiten sollen sie gegenüber den zahlreicheren Mausnutzenden nicht benachteiligen.

Die vom Browser vorgesehene Kennzeichnung des Tastaturfokus hebt sich von dunklen Seitenhintergründen meist nicht so gut ab. Das muss dann durch eine entsprechende Gestaltung ausgeglichen werden.

Spracheingabenutzer können Bedienelemente wie Links, Tasten oder Eingabefelder aktivieren, indem sie den sichtbaren Namen sagen, auch in der Verbindung mit Befehlen (z. B. Klick "Abschicken"). Wenn die sichtbare Beschriftung nicht in dem hinterlegten zugänglichen Namen des Bedienelements (also dem Text, der programmatisch als Beschriftung ermittelt wird) vorkommt, lässt sich das Bedienelement gegebenenfalls nicht oder nur über Umwege mittels Spracheingabe aktivieren.

Bedienelemente haben manchmal einen zugänglichen Namen, der von der sichtbaren Beschriftung abweicht, weil er über nicht sichtbare Attribute wie aria-label oder über nur bei Mausnutzung eingeblendete Attribute wie title festgelegt wird. So könnte etwa die sichtbare Beschriftung "AGB akzeptieren" durch den hinterlegten zugänglichen Namen "Allgemeine Geschäftsbedingungen annehmen" ersetzt werden. Wenn Spracheingabenutzer nun Klicke "AGB akzeptieren" diktieren, kommt dieser Text so nicht im zugänglichen Namen vor, die Eingabe schlägt deshalb fehl.

Manchmal wird versteckter Text benutzt, um sichtbare Beschriftungen zu erweitern, oft auch in der Absicht, Hilfsmittelnutzern zu helfen. Das ist dann in Ordnung, wenn die sichtbare Beschriftung durchgehend in dem zugänglichen Namen enthalten ist, am besten zu Beginn.

Standard-HTML-Bedienelemente wie Links (a-Element) und Formularelemente (input, button, checkbox etc.) haben Namen, Rollen, Wert und Zustände, sofern sie gemäß Spezifikation umgesetzt sind und sind für Hilfsmittel wie Screenreader generell erkennbar. So bekommen etwa blinde Nutzer mit, wenn sie auf einen Link tabben und können diesem dann folgen. Auch Zustände, beispielsweise einer Checkbox (ausgewählt oder nicht ausgewählt) werden vermittelt. Interaktive Schaltflächen sollten deshalb mit Hilfe von geeigneten nativen HTML-Elementen umgesetzt werden, damit ihre Bedeutung klar wird.

Falls ungeeignete (weil nicht semantische) Elemente (etwa div oder span) mithilfe von JavaScript zu Links oder Bedienelementen umfunktioniert werden, kann die Semantik mit Hilfe von WAI-ARIA bereit gestellt werden. Dies betrifft auch Komponenten (Widgets wie z. B. Tabpanels, Akkordeons etc.), die in nativem HTML so nicht zur Verfügung stehen und mit Hilfe von nicht semantischen Elementen und Scripten umgesetzt sind. WAI-ARIA Attribute helfen, diese zu verstehen, indem semantische Informationen vom Browser an die Hilfsmitteltechnologien übermittelt werden.

Linking labels to their associated input fields ensures that the structure of a page is defined and accessible regardless of presentation:

• The screen reader reads the labels aloud as the user wanders through the form elements.

• One advantage of using native label-elements: Mouse users can click on the label to set the focus to the associated form element.

Specifying the input purpose allows new assistive technologies to display additional information for form fields that refer to user data, regardless of the field's caption and regardless of the natural language of the offer.

Additional information can be images or icons provided by a browser plugin or external assistive technology that are displayed above or in front of the respective input field, for example when users press a certain key combination. For people who have difficulty reading or prefer to communicate via images, this makes it easier to identify user-related fields in forms.

Further provides autocomplete input suggestions for the field, which users can easily accept. This makes text entry easier.

It is important for keyboard users to see where the keyboard focus is currently located, i.e. which link will be triggered when they press the Enter key.

Many websites make it easier for mouse users by reacting to the fact that the mouse pointer is over a link. Then, for example, the text or background color changes or the link text is underlined. This support should also work for keyboard users, websites should not disadvantage them compared to the more numerous mouse users.

The browser's keyboard focus marker usually does not stand out as well against dark page backgrounds as it does in the browser's or the user's "normal" view. This must then be compensated, for example by a colored highlighting of the selected link.

Language input users can activate controls such as links, buttons, or input fields by saying the visible name, even in conjunction with commands (e.g. Click "Submit" button). If the visible label does not appear in the stored accessible name of the control (i.e., the text that is programmatically determined as the label), the control may not be activated or may be activated only indirectly using speech input.

Sometimes controls have an accessible name that differs from the visible label because it is defined by non-visible attributes such as aria-label or via attributes that are only displayed when the mouse is used, such as title . For example, the visible label "Accept T&C" could be replaced by the stored accessible name "Accept General Terms and Conditions". When voice input users now dictate click "Accept T&C", this text does not appear in the accessible name, so the input fails.

Sometimes hidden text is used to extend visible labels, often with the intention of helping assistive technology users. This is fine if the visible caption is included throughout the accessible name, preferably at the beginning.

Standard HTML controls such as links (a-element) and form elements (input, button, checkbox etc.) have names, roles, value and states, provided they are implemented according to specification and are generally recognizable for tools such as screen readers.  For example, blind users can see when they tab to a link and can then follow it. States, for example of a checkbox (selected or not selected), are also conveyed. Interactive buttons should therefore be implemented using suitable native HTML elements so that their meaning is clear.

If unsuitable (because non-semantic) elements (such as div or span) are converted to links or controls using JavaScript, the semantics can be provided using WAI-ARIA. This also applies to components (widgets such as tab panels, accordions, etc.) that are not available in native HTML and are implemented using non-semantic elements and scripts. WAI-ARIA attributes help to understand them by passing semantic information from the browser to the assistive technologies.