Skip to content
SERPCompass

Links, buttons and form fields without accessible text, and a missing lang attribute

Give every link and button words that say what it does: visible text, or an aria-label when it shows only an icon. Give an image link alt text that names the destination. Tie every form field to a visible label element. And put the page's language on the html element, such as lang="en", so screen readers read the page with the right pronunciation.

Last updated 29 October 2026, when every step was checked against the vendor's documentation.

Why it matters

Screen readers announce a link or a button by its accessible name: the text inside it, the alt text of an image inside it, or a label given with aria-label or aria-labelledby. A link or button with none of these, typically an icon or an image without alt text, gives its user no idea where it goes or what it does. Lighthouse's accessibility audits, which run Deque's axe-core rules, check both: links need a discernible name and buttons an accessible name.

A form field needs a name too. The W3C's forms tutorial asks you to tie a <label> element to each field whenever possible, either with for and the field's id or by wrapping the field in the label. aria-label is read by screen readers but shown to no one, and the tutorial calls the title attribute less reliable and not recommended.

Placeholder text is a special case. The W3C's HTML accessibility mappings use a field's placeholder as its name when no label, aria-label or title gives one, and axe-core's label rule accepts it, so SERPCompass does not count such a field. The W3C's tutorial is still plain that placeholder text is not a replacement for labels: it disappears once someone starts typing, it is often shown in low contrast, and screen readers do not treat it as a label. Deque calls it not a recommended solution. Give the field a visible label anyway.

The lang attribute on the <html> element tells assistive technology which language the page is in. Without it, a screen reader reads the page in its user's default language, accent and all, and WCAG asks for the page language to be set this way (success criterion 3.1.1, level A). It is not a Google ranking signal: Google says it works out a page's language from its visible content and does not use lang attributes.

SERPCompass rates all four findings as notices, its lowest severity: they decide whether people using assistive technology can use your pages, not whether search engines find them. One icon link or unlabelled search field in a template every page shares puts every page on the list, and one fix to that template clears them all.

The audit findings this guide fixes: Links without accessible text; Buttons without accessible text; Form fields without labels; Missing html lang attribute.

Find every page with this problem

Run the free scan on your domain. On every page it crawls, it checks each <a> with an href (mail, phone and # links included), each <button> and each element with role="button", and counts those with no name: no text inside, no alt text on an image inside, no <title> in an icon's <svg>, and no aria-label, aria-labelledby or title. A submit, button or reset <input> counts when it has no value, aria-label or title, even though browsers show their own word, such as Submit, on a submit button with no value, because that word does not say what the form does. Form fields (inputs other than hidden, submit, button, reset and image, plus <select> and <textarea>) count when no <label for> matches their id, no <label> wraps them and they have no aria-label, aria-labelledby, title or placeholder; fields hidden with aria-hidden="true" or the hidden attribute, or inside such an element, are skipped. Pages whose <html> element has no lang value are flagged too. The scan reads the HTML, not the styles, so text hidden with CSS still counts as text. It shows your most urgent findings with the number of pages each affects; the Gap Report and a SERPCompass workspace list the pages. To find the elements on one page, run Lighthouse's accessibility audit in Chrome's developer tools: its link-name, button-name, label and html-has-lang audits cover the same ground.

Scan my site free

How to fix it on your platform

Colour contrast, keyboard focus, headings and other accessibility checks are not covered here; this guide is not an accessibility audit.

WordPress

  1. A classic theme prints the language in its <html> tag with language_attributes(): the opening tag in header.php should read <html <?php language_attributes(); ?>>. WordPress then adds lang with the site's language code, such as en-US. Make the change in a child theme, so a theme update does not undo it.
  2. For an image that links somewhere, select the Image block, open the block settings sidebar with the Settings button next to Save or Publish, and on the Content tab type Alternative text that says where the link goes. Do not mark a linked image as decorative.
  3. In a Search block, keep the label showing: the Toggle search label button in the block toolbar hides it, and the placeholder text the block offers disappears as soon as visitors type.
  4. An icon link or button that a theme or plugin prints needs a label from that theme or plugin: send its developer the page and the element.

Sources: language_attributes() (WordPress developer reference); get_language_attributes() (WordPress developer reference); get_bloginfo() (WordPress developer reference); Child themes (WordPress theme handbook); Image block (WordPress documentation); Functional images (W3C WAI images tutorial); Search block (WordPress documentation).

Shopify

  1. Shopify's accessibility best practices for themes ask for the lang attribute on the html element and a label for every form field: a visible label, a floating label, visually hidden text or aria-label, with for attributes tying labels to inputs.
  2. To check the language, duplicate your theme as a backup, then from your Shopify admin go to Online Store, click the ... menu and select Edit code. Open theme.liquid, the default layout, in the layout folder.
  3. Make its opening tag carry the language of each request: <html lang="{{ request.locale.iso_code }}">. request.locale is the locale of the request, and its iso_code is an IETF language tag such as en. Save.
  4. For fields, buttons and links that an app adds, contact the app's developer; edit only your own theme's code.

Sources: Accessibility best practices for Shopify themes (Shopify.dev); Editing theme code (Shopify Help Center); Layouts (Shopify.dev); request (Shopify Liquid reference); shop_locale (Shopify Liquid reference).

Wix

  1. Set the site language: in your site's dashboard, go to Settings, click Language & Region and choose your language from the Site language drop-down. Wix says this gives screen readers and other assistive technology what they need to render your content.
  2. Wix says most of its elements already carry the ARIA attributes they need. For a custom element, turn on developer mode, select the element, open its More actions menu, choose Accessibility, click Add Attribute, pick label, type the label and click Add.
  3. For an image that links somewhere, click it, click the Settings icon and describe where the link goes under What's in the image?, then press Enter. Wix asks you not to mark linked images as decorative.
  4. The Accessibility Wizard (Settings > Accessibility Wizard > Scan Site) checks the main site language and image alt text; descriptive link and button text is on its list of things to check yourself.

Sources: Accessibility: setting and managing your site's language (Wix Help Center); Accessibility: adding ARIA attributes to custom web applications (Wix Help Center); Accessibility: preparing your images and galleries (Wix Help Center); Accessibility: using the Accessibility Wizard (Wix Help Center).

Plain HTML

  1. Put the page's language on the <html> element: <html lang="en">, or a regional tag such as en-GB. Mark a passage in another language with its own lang, such as <span lang="fr">.
  2. Give every link words that say where it goes. For a link or button that shows only an icon, add aria-label, such as <a href="/cart/" aria-label="Cart">. For an image link, put the destination in the image's alt.
  3. Write a button's action inside it, as in <button>Search</button>, and give an <input type="submit"> a value such as Send message.
  4. Tie a visible <label> to every field: <label for="email">Email</label> with <input id="email">, or wrap the field in the label. Use aria-label or aria-labelledby only where a visible label is truly not possible, and keep the placeholder for an example, not for the label.
  5. Do not hide a link's or button's only text with display: none or aria-hidden="true": that hides it from screen readers too.

Sources: lang global attribute (MDN); html element must have a lang attribute (Deque University, axe-core rule html-has-lang); Links must have discernible text (Deque University, axe-core rule link-name); Buttons must have discernible text (Deque University, axe-core rule button-name); Labeling controls (W3C WAI forms tutorial); Form instructions (W3C WAI forms tutorial); Functional images (W3C WAI images tutorial).

Examples

  • Bad 
    <a href="/cart/"><svg aria-hidden="true">...</svg></a>

    An icon with no name: a screen reader announces a link and nothing about where it goes.

  • Good 
    <a href="/cart/" aria-label="Cart"><svg aria-hidden="true">...</svg></a>

    The same icon link, now announced as Cart.

  • Bad 
    <button class="menu-toggle"><span class="icon-bars"></span></button>

    A menu button with no text and no label.

  • Good 
    <button class="menu-toggle" aria-label="Open menu"><span class="icon-bars"></span></button>

    The button says what it does.

  • Bad 
    <input type="email" name="email" placeholder="Email">

    SERPCompass does not flag this, because the placeholder gives the field a name. It still vanishes as soon as someone types: add a visible label.

  • Good 
    <label for="email">Email</label>
<input type="email" id="email" name="email" placeholder="name@example.com">

    A visible label tied to the field; the placeholder only shows an example.

  • Bad 
    <html>

    No language: screen readers fall back to their user's default language.

  • Good 
    <html lang="en">

    The page's language, set once for the whole page.

Common mistakes

  • Icon-only links and buttons with no label: social media icons, a cart, a search magnifier, a menu toggle, a close button.
  • Image links whose image has no alt text, or alt="", which leaves the link with no name.
  • Using placeholder text as the only label of a field.
  • Hiding a link's or button's only text with display: none or aria-hidden="true".
  • Setting lang to the wrong language, such as en on a page in German, so screen readers read it with the wrong pronunciation.
  • Writing click here on every link. The link has a name, so this check passes, but the name says nothing about where it goes: the internal links guide covers descriptive link text.

Questions and answers

What does Links do not have a discernible name mean?

It is Lighthouse's accessibility audit for links, which runs axe-core's link-name rule: a link needs a name a screen reader can announce, such as text inside it, the alt text of an image inside it, or an aria-label. A link that fails is usually an icon, or an image without alt text. Give it words, or an aria-label that says where it goes.

Is placeholder text enough as a label?

Not for people. The W3C's HTML accessibility mappings use the placeholder as a field's name when nothing else names it, and axe-core accepts it, so SERPCompass does not flag such a field. But the W3C's forms tutorial says placeholder text is not a replacement for labels: it disappears as soon as someone types, and screen readers do not treat it as a label. Give every field a visible label.

Does the html lang attribute affect SEO?

Not in Google: it says it works out a page's language from the visible content and does not use lang attributes. Set it for people instead: screen readers use it to read the page with the right pronunciation, and WCAG asks for it. To tell Google about language versions of a page, use hreflang annotations.

Do empty links hurt SEO?

They tell Google nothing about the page they lead to. Google uses a link's text as its anchor text, the alt text of an image that is a link, and the title attribute only as a fallback when the link is empty. We make no ranking claim for buttons or form fields: those findings are about people using assistive technology.

How do I label a button that only shows an icon?

Give the button element an aria-label that says what it does, such as Search or Close menu. Deque's rule for buttons accepts a non-empty aria-label, text inside the button, or aria-labelledby pointing at visible text, and SERPCompass counts all three. For an input button, put the words in its value attribute.

Sources

Every step above was checked against these documents on 29 October 2026. Vendors change their menus; if a step no longer matches, the vendor's page is the authority.

Start with a free scan of your site.

Two to five minutes, no account. You get your three most urgent findings, and the exact count of everything else.

Free, 2–5 minutes, no account needed.