Skip to main content

Top 10 Accessibility Issues in Portugal

Web developers worldwide have found 105 million A11Y issues on 13 million checked web pages.
Here are the most common issues detected by Rocket Validator on Portugal websites.

Last update: Wednesday, October 21, 2026

1. Images must have alternative text. 42.70%

Every <img> element must have alternative text so that screen readers can convey the image's meaning to users who cannot see it. You can provide alternative text using the alt attribute, aria-label, or aria-labelledby. Decorative images that convey no information should use an empty alt attribute (alt="") to tell assistive technology to skip them.

2. Buttons must have discernible text. 28.25%

Buttons without discernible text are invisible to screen reader users, making it impossible for them to understand what a button does or where it leads. Every <button> element and any element with role="button" must have an accessible name provided through visible text content, an aria-label attribute, an aria-labelledby reference, or a title attribute.

3. Elements must only use supported ARIA attributes. 9.47%

ARIA attributes must only be used on elements whose roles support them. When an attribute like aria-checked appears on a role that doesn't allow it, such as textbox, assistive technologies may announce contradictory or nonsensical information — or silently break accessibility for the entire component. To fix this, identify each element's role (explicit or implicit), verify which ARIA attributes that role permits, and remove or relocate any unsupported attributes.

4. Certain ARIA roles must be contained by particular parents. 6.79%

Certain ARIA roles must be nested inside specific parent roles to function correctly. When a role like listitem appears outside its required parent (e.g., list), assistive technologies cannot interpret the relationship between elements, breaking the intended user experience. Fix this by ensuring every ARIA role that requires a parent is wrapped in an element with the correct parent role, either in the DOM or via aria-owns.

5. Form elements must have labels. 5.90%

Every form element — such as text inputs, checkboxes, radio buttons, and select menus — must have a programmatically associated label so that assistive technologies can identify and announce the purpose of each field. Without these labels, screen reader users cannot determine what information is expected, and users with motor impairments lose the benefit of a larger clickable target area that a properly associated <label> provides. Fix this by using <label> elements with matching for/id attributes, wrapping inputs in <label> elements, or using aria-label or aria-labelledby attributes.

6. Certain ARIA roles must contain particular children. 2.59%

Certain ARIA parent roles require specific child roles to function correctly. When a parent element has an ARIA role like list, menu, tree, or tablist, it must contain children with the corresponding expected roles (e.g., listitem, menuitem, treeitem, tab). Missing these required children breaks the semantic relationship that assistive technologies depend on to communicate structure and context to users.

7. Select element must have an accessible name. 1.15%

Every <select> element must have an accessible name so that screen reader users can understand what choice the dropdown is asking them to make. Without a programmatic label, assistive technologies cannot convey the purpose of the select field, leaving users to guess what they should choose. Fix this by associating a <label> element with the <select>, or by using aria-label or aria-labelledby to provide an accessible name.

8. Non-empty <td> elements in larger <table> must have an associated table header. 1.09%

Every non-empty <td> element in a larger data table (3 or more columns and 3 or more rows) must be programmatically associated with one or more table headers. Without these associations, screen reader users cannot understand the relationships between data cells and their corresponding row or column headers. To fix this, use <th> elements with scope attributes for simple tables, or the id and headers attributes for complex tables.

9. Input buttons must have discernible text. 1.08%

Input elements used as buttons — such as <input type="button">, <input type="submit">, and <input type="reset"> — must have discernible text that communicates their purpose to all users. When an input button lacks an accessible name, screen reader users have no way to determine what the button does. To fix this, provide a value attribute, aria-label, aria-labelledby, or title attribute with meaningful text.

10. ARIA roles used must conform to valid values. 0.98%

Every element with a role attribute must use a valid ARIA role value. Invalid roles — caused by typos, made-up values, or the use of abstract roles — prevent assistive technologies from understanding an element's purpose. To fix this, ensure every role value exactly matches a defined, non-abstract role from the WAI-ARIA specification.

Switch to Spanish or Portuguese
🌍 Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
€5 / week

1K Weekly

1,000 monthly checks. Cancel anytime.

Get 1K Weekly →

Join teams across 40+ countries