Audit Report
on AccessibilityJoomla! WCAG Audit

The images representing the extensions have no alt attributes at all, meaning that they are neither marked as pure decoration, nor have an image description. In these cases, screen readers and browsers will try to use the filename for the images as the text alternative.

Suggestion: As these images are part of the card to open the details view of the plugin, consider adding an empty alt attribute (alt="") to the images.

The QR Code when setting up Multi-Factor Authentication has no text alternative as an alt attribute is not present on the <img> element. This makes it more difficult for a screen reader user to locate and use the QR code.

At least add the alt="QR Code" attribute to the element.

Note: For making QR codes even more accessible, see Accessible QR Codes – The Ultimate Guide.

The Joomla! logo on the top left of the administration template has an empty alt attribute on the "Home Dashboard" page, and "Back to Dashboard" on subsequent pages.

The image is also not linked on the main dashboard page, but linked on other pages.

This is problematic in two ways: The link to the Dashboard is not consistent between pages, and some screen reader users rely on the consistent existence of controls to orient themselves on the page. In addition the visible label of the link is not included in the accessible name of the link. This means that voice input users can struggle to activate the link.

Treat the logo like the "Home Dashboard" link. Ensure the logo link is also on the "Home Dashboard" page, include the visible "Joomla!" text and the words "Home Dashboard" for consistency. Use aria-current="page" as the indicator that the user is on the Dashboard, as you do on the dedicated "Home Dashboard" link:

<a class="logo" href="…" aria-current="page">
 <img loading="eager" decoding="async" src="…" alt="Joomla! – Home Dashboard">
</a>

When a user selects which MFA method they want to use, they are presented with a list of links:

These links contain the link name (Passkey, Code by Email, …) an image that represents that method, and a hint text that is the same text as the actual link name. As the images have alt attributes and all three elements are part of the link, the Passkey link’s accessible name is “My Passkey Passkey Passkey” while the “Code by Email” link’s accessible name is “Code by Email Code by Email Code by Email”.

The passkey one just does not repeat the same value three times because the passkey was renamed to “My Passkey”.

There is no need for such a convoluted naming. Ensure that the alt attribute of the graphics are empty (alt="") and remove the duplicated hint text (Code simplified):

Current code:

<a class="…" href="…">
  <div class="…">
    <img src="…" alt="Backup Codes" class="…">
  </div>
  <span class="…">
    Backup Codes
  </span>
  <small class="…">
    Backup Codes
  </small>
</a>

Change to:

<a class="…" href="…">
  <div class="…">
    <img src="…" alt="" class="…">
  </div>
  <span class="…">
    Backup Codes
  </span>
</a>

Note: The helper text does not meet contrast requirements, but as the suggestion is to remove it, we did not specify this in detail.

The “Toggle Menu” button is implemented using a link and also does not convey the current state to users of assistive technologies.

This is the current HTML code:

<a id="menu-collapse" href="#" aria-label="Toggle Menu">
 <span id="menu-collapse-icon" class="icon-fw icon-toggle-on|off" aria-hidden="true"></span>
 <span class="sidebar-item-title">Toggle Menu</span>
</a>

Suggestion: Instead of using a link without a target, use a <button> element. In addition to conveying the correct semantics to screen reader users, this also enables the use of the space key in addition to the return key to activate the button.

Use aria-pressed on the <button> element to convey if the button is pressed or not.

Lastly, decide on the default state of the button and use that state as the button text.

<button id="menu-collapse" aria-label="Collapse Menu" aria-pressed="true|false">
 <span id="menu-collapse-icon" class="icon-fw icon-toggle-on|off" aria-hidden="true"></span>
 <span class="sidebar-item-title">Collapse Menu</span>
</button>

Alternative: Instead of using the aria-pressed attribute of the button to determine the current state of the button, you can also decide to change the button text:

<button id="menu-collapse" aria-label="Collapse Menu">
 <span id="menu-collapse-icon" class="icon-fw icon-toggle-off" aria-hidden="true"></span>
 <span class="sidebar-item-title">Collapse Menu</span>
</button>

<button id="menu-collapse" aria-label="Show Menu">
 <span id="menu-collapse-icon" class="icon-fw icon-toggle-on" aria-hidden="true"></span>
 <span class="sidebar-item-title">Show Menu</span>
</button>

Note: In general we do not recommend to use aria-label when the accessible name of the user interface element already has a visible text that can act as an accessible name. aria-label is often overlooked or miscopied and as its values are not immediately visible difficult to debug. Wherever you can either rely on the contents to label a user interface element or use aria-labelledby to point at an element ID with the visible accessible name.

The “Install from Web” view has no structure to indicate where the results of the search are. The skip link menu can only focus on the categories heading over the left side navigation, but there is no similar way to find the results quickly.

The individual headings for extensions are also <h4> elements while the “Categories“ heading is an <h3> element. Adding a “Results” heading level 3 would clarify the structure up.

In several places, “opens in a new tab/window” icons are shown in the interface, however this information is not conveyed programmatically as the icon is hidden from screen readers and other assistive technologies.

The issue affects all links out to the directory listing or the developer website.

Suggestion: Use aria-description="Opens in a new window or tab" to indicate that the link opens in a new window or tab.

The text filters are difficult and confusing to use. While the issues individually just barely meet the threshold of violations, their combination makes the UI difficult to use, especially on small screens.

The UI uses vertical ellipsis (⋮) as an indentation symbol, but this is not explained anywhere and creates noise in screen readers which announce 🗣️ Vertical Ellipsis Vertical Ellipsis, Vertical Ellipsis Publisher.

The table also shows cut off in a small viewport, which makes orientation difficult, especially with the constraint width due to extra padding on the page:

Unfortunately this kind of indentation cannot be conveyed well in tables. Consider using nested groups or <fieldset> elements instead, aligned by CSS grids. These would also allow to properly reflow the table in mobile.

The filter options button does not indicate that it expands content on the page. The only indicator that the content is expanded is the existence of the filter options elsewhere on the page.

This is problematic as people who use zoom to interact with the page have the impression that nothing has happened. Screen reader users will also have a more difficult time to find the filter options as they are not in the proximity of the expanded button.

Suggestion: Add the aria-expanded attribute to the filter options button. Show the options directly after the button that expands the options. Make sure that the button clearly communicates its expanded state visually, too, for example by using different icons.

To allow screen reader and other assistive technologies to interact with the content in a meaningful way, information that is conveyed visually needs to also be available to those tools programmatically.

On websites and in web apps, this usually means clear accessible names, states and structure. The media manager interface misses to convey the information in various places.

In the grid view, the focusable icons for folders have no accessible name and no role. The checkmarks to select individual items have no role and hence also cannot receive the name through aria-label. Their status is not set. The checkboxes cannot be set using space or enter.

The ellipsis button that shows the sub menu to manage files does not expand using the arrow keys, but once expanded behaves like a toolbar with arrow navigation. This is inconsistent and also not communicated through roles and properties.

Keyboard interaction is inconsistent in the ellipsis menu in general. Sometimes the arrow key works as expected, occasionally the page scrolls, and sometimes the preview of a file is opened.

Pressing ESC does not close the ellipsis menu.

The table view is not keyboard accessible at all. Its columns can be sorted, but there is no programmatic indication of the current sorting direction.

In both views, the information panel cannot be filled when using the keyboard as activating an item immediately opens the folder or shows a preview of the file.

The toolbar also has accessibility issues:

• The “Toggle select all” checkbox is implemented as a regular checkbox, and hence works as expected. (Consider dropping the word “toggle” from its accessible name, it is unnecessarily wordy and can be confusing. That the UI element toggles is implied by the fact that it is a checkbox.)

• The file path navigation does not well convey what it is visually and also uses a navigation (<nav>) element that has the aria-label of Breadcrumb. As this is not a classical navigation like a page navigation, consider using a different element. Pick a better accessible name than “Breadcrumb”, for example “Current path”.

• The search field that filters the results shows an alert visually when there are no matches, but does not convey it to the assistive technologies.

• The sort button (“Change ordering”) opens two select boxes that allow you to select what to order by and in which direction, but the select boxes are positioned after other buttons and the button does not convey that something would open. This makes the actual sorting options difficult to find.

• The buttons to change the grid size look disabled when the minimum/maximum grid size is selected, but they are not made disabled programmatically. So the icons need to meet contrast requirements (at least 3∶1 contrast).

• The switch from grid to list view and vice versa is named “Toggle between grid and table views” and gives users no indication on what mode is selected.

• The toggle item info button does not indicate if the item info pane is shown or not.

The folder tree navigation is unclear to users and not properly implemented. Especially there roles need to be properly nested and expanded/collapsed set properly. See this example from W3C/WAI. That said, even the WAI treeview works sub-optimally on platforms that do not support treeviews natively, namely macOS and iOS.

Suggestion

Instead of fixing the individual issues, it makes sense to re-think how the media manager is built and works and plan it from the ground up in an accessible way.

The tag selection interface is working poorly with the keyboard and when using screen readers. The user first has to move past the existing tags with the keyboard. Screen reader users focus on the “Remove item” buttons, which means they can only review which tags are selected by repeatedly hearing ”Remove item” again and again.

In addition, the remove buttons come before the “Type or select some tags” text field and while the visual “Tags” label communicates the purpose of the next UI elements well, this is not really available for users of assistive technologies.

In addition, focused but not selected options in the combobox are announced as selected. Removing a tag makes the page lose track of the focus and puts the focus to the top of the page. The “Remove” buttons are too small (less than 24×24 pixels).

The same tag selector is also present in the Backend Options under “Log Priorities”:

Suggestion: Remove the actual tags from before the dropdown. Show the tags after the selector. Refer to the selected tags using aria-describedby and by marking them selected in the dropdown. Do not mark unselected but focused options as selected. Use a <fieldset> element or a group role to make clear that the user is interacting with tags.

When uploading a plugin file, the maximum file size is available for visual users in context with the drag and drop/file upload button.

However, users of assistive technologies arrive at the button before noticing the upload limit, which might lead to larger files being uploaded.

Suggestion: Use aria-describedby to assign the upload limit to the button by referencing the upload limit text’s ID value as the aria-describedby value:

<p>
  <button id="select-file-button" type="button" class="btn btn-success" aria-describedby="maxUploadSize">
    Or browse for file
  </button>
</p>
<p id="maxUploadSize">Maximum upload size: <strong>‎128.00 MB</strong></p>

For visual users the design and positioning of the tags on the page makes it clear that the links are tags. A user using assistive technology like a screen reader has no hints that the links are tags.

Use a grouping container that is labeled or label the existing list.

Currently:

<ul class="tags list-inline" style="">
  <li class="list-inline-item tag-2 tag-list0">
    <a href="…" class="btn btn-sm btn-info">Millions</a>
  </li>
  …
</ul>

Suggested:

<ul aria-label="Tags" class="tags list-inline" style="">
  <li class="list-inline-item tag-2 tag-list0">
    <a href="…" class="btn btn-sm btn-info">Millions</a>
  </li>
  …
</ul>

When setting the password for the administrator of the Joomla installation, there is a password requirement of at least 12 characters.

However the only error information a screen reader or assistive technology user would get its that “This value is not valid” as long as the password is less than 12 characters long. That there is a 12 character requirement is not conveyed to assistive technology users as they enter the password. There is an <output> element that only announces “Password doesn’t meet the site’s requirements.” when an isufficient password is read.

Ensure that the requirement “Enter at least 12 characters” is associated with the password field using aria-describedby attribute pointing at the message‘s ID attribute. Also consider using autocomplete="new-password".

When updating Joomla, the user has to check a checkbox to enable the “Start update” button.

While there is an exception for disabled buttons having sufficient (4.5:1) contrast, the “Start update” button is a link that only looks disabled. It still can be focused and clicked, but there is nothing happening.

To make the button properly act like a disabled button, add aria-disabled="true" and tabindex="-1". (Remove both attributes when enabling the button.) Alternatively, you can set the link to inert while disabled, which will prevent all interactions.

Sometimes, the Save & Close button has additional options which are signaled by a drop down arrow on the right of the button with the accessible label “Toggle Dropdown”.

In the keyboard focus order, however, the dropdown button comes first, meaning that a user comes across the secondary information first, before the primary one.

For screen reader users, the announcement is also confusing:

🗣️ Save, button; Toggle Dropdown, menu pop up, button; Save and Close, button

While the announcement of “Toggle Dropdown, menu pop up, button” could mean that there are alternatives to saving the document, the actual options are for “Save & Close”. In addition, the accessible name “Toggle Dropdown” is non-descriptive, especially as the role of the element already conveys that this is a “Dropdown”.

Suggestion: Ensure that the order of the buttons in the code matches the order of the buttons on screen. Use a different accessible name for the “Toggle Dropdown” button, for example “Save options” or similar.

For people who have low vision or other visual disabilities, distinguishing between different UI elements and seeing the state of various UI elements is important.

The current menu item is only indicated visually by using color alone.

The color also does not have much contrast compared to other colors in the menu, which have the following background colors:

• Non-selected menu: --sidebarwrapper-bg / rgb(31, 48, 71) / dark blue

• Non-selected sub menu: --main-nav-ul-bg / rgb(38, 60, 89) / slightly lighter blue

• Selected menu item: --main-nav-mm-active-bg / rgb(46, 72, 107) / even slightly ligher blue

These colors all lack the minimum required contrast to make them distinguishable (3∶1), however the sub-menu items are indented, which makes them identifiable enough.

Ensure a non-color way to indicate the current page. Use an icon or other indicator. Alternatively you can ensure that the contrast between non-current items and current items is more than 3∶1, like in the dark theme:

The contrast of text elements must be at least 4.5∶1, unless the text is larger than 19 pixels and bold or larger than 24 pixels. In those instances the minimum is 3∶1.

Guided Tour

The cancel button of the "Guided Tour" has a contrast ratio of 2.26∶1, which is less than 4.5∶1.

Suggestion: Change the text color to a color that matches the minimum contrast ratio, for example use rgb(103, 103, 103) for the text color on the beige rbg(230, 230, 230) background.

Empty Dashboard Card Message & Character Counter

In light mode, the dashboard message that shows in an empty dashboard card has a contrast of less than 4.5∶1 as the --text-muted-color (rgba(33, 37, 41, 0.75)) is further lightened by an additional 0.7 opacity value, resulting in a 3.29∶1 color contrast. The rendered font size is 16px, too small for allowing a 3∶1 contrast which requires text to be bold (which this is) and a font size of 18.5px or larger.

The dark mode version of the message exceeds the minimum of 4.5∶1.

In the edit articles view, the same color and opacity is used to show the remaining characters of the Meta Description field:

The same issue exists in the Backend Options view where the “Site Meta Descriptions” field has a similar information message.

Suggestion: Remove the opacity: 0.7; modifier from the muted text – you already set a muted color here, further muting it through opacity makes little sense. Rather change the muted text color.

Installer Wizard

In the installer wizard, the POPULAR badge in extension headings has a contrast of 1∶1, as the text is white on white:

To make the badge easier to see, I have replaced the white background color with a purple background color:

Either remove the badge from the code or use a contrasting color scheme.

MFA Setup

Almost all text on the MFA Setup page has insufficient contrast in both light and dark modes:

The same light gray text is also used on the MFA setup detail pages, where links have also insufficient contrast:

Update Joomla

The text of the tip in the backup on update box does not have sufficient contrast:

The icon for Commercial, a white $ on yellow background, and the corresponding full-word badge on the detail page of a plugin do not meet contrast requirements.

While for the icon, a 3:1 contrast is sufficient, using the same color for the full-text badge makes sense.

Suggestion: Use a dark text color for the icon and word, consider to add a dark outline around both the icon and the badge.

At a viewport of 320px wide, the selector of items in the table is compressed in a way to hide the current number. While users can open the <select> element to understand what number is currently selected, it is an unnecessary step.

Suggestion: Ensure a minimum width that preserves the number of entries in the table.

In small viewports, when opening the three-dot menu to show toolbars, the editor disappears when scrolling the page. This means that there is only an empty space instead of the editor.

See the attached video for details on how the editor is hidden when scrolling begins (and only reappears when scrolling fairly to the top of the page.

Suggestion: Don’t hide the editor at any times.

In contrast to the Text filters, the Permissions view reflows to meet the 320px wide viewport quite well, however the value of the drop down select fields is hidden when the viewport is small.

Suggestion: Ensure that the drop down select is shown on its own line to allow the current setting to be displayed.

Consider changing to a different configuration, either with radio buttons or checkboxes, which might allow for quicker access:

• Default (Not Allowed)

• Allowed

• Denied

This would make the current outcome more clear and also would mean that screen reader users could know what the current default/inherited value is before making a selection. Currently they need to jump to the calculated setting first and then navigate their way back to the selector. It could be nicely grouped in fieldsets.

The minimum required contrast ratio for graphical elements that carry information or functionality is 3∶1. This is especially important when the graphical elements are part of buttons.

Guided Tours

In the "Guided Tours", the X in the cancel button has a contrast that is less than 3∶1 against the gray background:

Use a darker color, for example rgb(131, 131, 131) instead of the semi-transparent rgba(128, 128, 128, .75).

Backend Edit Form Pattern

The small × symbol to unselect a category is set to a color that meets the requirement, but when not hovered and focused the symbol is set to opacity: 0.5, causing the contrast to dip under the required minimum of 3∶1.

Ensure that the contrast meets the 3∶1 requirement at all times.

MFA Setup

The star that indicates the default Passkey (and supposedly other defaults as well) has insufficient color contrast:

The yellow rgb(255, 181, 21) on white rgb(255, 255, 255) has the contrast ratio of 1.76∶1. A suggestion for the foreground that meets the 3∶1 requirement is rgb(196, 138, 0).

Graphics and user interface elements that consist of graphics must meet a minimum contrast ratio of 3∶1. The buttons to set featured and published status do not meet that requirement in light mode:

The light gray rgb(205, 205, 205) on rgb(255, 255, 255) has a contrast ratio 1.58∶1. We suggest at least a darker gray, like rgb(148, 148, 148).

In both, light and dark mode, the borders of checkboxes have insufficient contrast:

• In light mode: rgb(222, 226, 230) on rgb(255, 255, 255) has a contrast ratio of 1.3:1. Suggestion: rgb(142, 149, 156).

• In dark mode: rgb(47, 51, 58) on rgb(23, 28, 36) has a contrast ratio of 1.34∶1. Suggestion: rgb(101, 103, 106).

Some checkboxes are barely visible versus their surroundings due to low contrast borders. Here, both in the light mode and in dark mode, the borders are so low contrast that it is barely (in light mode) and almost impossible (in dark mode) to see the checkbox, even without a disability.

Here is an example from the Update Joomla screen:

And here is an example, the remember me checkbox, from the Frontend Authentication Flow:

Suggestion: Ensure that the border around the checkbox meets at least a 3:1 contrast ratio. This is even an issue when high-contrast mode is switched on in user settings.

The way current menu items are highlighted has lower than 3∶1 contrast ratio:

They blue-gray rgb(80, 90, 129) on rgb(36, 50, 99) has a contrast ratio 1.82∶1. Use a lighter border color, for example rgb(118, 125, 154) to meet the contrast requirements.

Also, neither the first nor second level submenus have sufficient contrast between the light gray focus indicator and the white and off-white backgrounds.

Ensure that all focus indicators have sufficient contrast against the background. See this excellent article by Sara Soueidan on how to ensure a great focus indicator in every situation.

Tooltips are little windows that show additional secondary information, usually on hover with a pointer device like a mouse. However, not every user can use a pointer device. Also, the user might need to move the pointer to read the content of the tooltip. This means there are additional requirements for tooltips that the Joomla! backend does not meet.

01 – Backend Template

The implemented tooltip has several problems and requirements:

1. It cannot be operated using the keyboard. This means that keyboard users are unable to see the content of the tooltip at all. The tooltip invoker (the lock icon in this case) needs to be keyboard focusable. Current, a <div> element is used, which is not focusable. Use either a <button>, or tabindex="0" on the <div>.

2. The invoker points at the tooltip for an accessible name using the aria-labelledby attribute. This is generally OK, but as the <div> is a generic element and thus cannot have an accessible name, either use a <button> element, or add a role="button".

3. Ensure that the tooltip stays open when the user hovers over the tooltip and moves the focus away from the invoker.

4. Allow the user to close the tooltip using the invoker button.

08 – Backend List View Pattern

The tooltip in the article table is neither dismifssible (without moving the pointer or focus) nor hoverable by the pointer.

06 – MFA Setup

The “Default” tooltip that appears when hovering the star/default icon in the Passkeys list (and maybe elsewhere) also fails the requirements:

10 – Frontend User Forms

The edit buttons in the frontend have tooltips assigned to them that detail what gets edited. These tooltips do not show in small viewports and cannot be dismissed without moving the keyboard focus.

Suggestion

In general, we advise against using tooltips as they can easily introduce accessibility issues. A small expand/collapse section (preferably implemented using the <details> element) that opens inline avoids most of the issues.

The list and grid of extensions consists of clickable <div> elements. Keyboard users are unable to open the extension information and install an extension. The keyboard order skips over most of the UI and only interacts with the link that leads to the external ratings.

Suggestion: Ensure that every item uses a link or a button to open the details view. Consider ordering the information in a way that prioritizes the plugin name and information. Maybe this view is due for a full redesign?

When choosing an MFA method, there are multiple buttons that have no functionality and are just obstacles for keyboard users:

• The cog/Toggle Toolbar button opens an empty toolbar.

• The ellipsis/More Elements button does nothing.

• The hamburger/Toggle Menu button changes to an X but does nothing else.

Suggestion: Remove unused buttons.

When setting the “Start Publishing”, “End Publishing”, and “Created Date” dates for an article, the date picker component is completely inaccessible by people using the keyboard and for screen reader users.

The keyboard focus stays in the input field with the date, and while some arrow key input is shown as changes in the date picker, the datepicker is not set up to be interacted with using the keyboard. For example, it is impossible to confirm a (visibly selected) date, or a time.

There is no feedback for screen reader users to know where they are in the calendar grid. The links for next year/month use links without href attributes, which makes them unfocusable.

The select boxes for hour and minute have no accessible names.

Suggestion: Replace this implementation with an accessible implementation.

On the article list view, the rows of articles can be reordered using drag and drop. This functionality is not otherwise available to users who do not use pointer devices or are able to use dragging movements.

The ability to reorder the articles needs to be accessible for people using keyboard input as well as people who cannot perform drag and drop movements. The easiest way is to add arrows next to the drag handles that allow reordering of the articles.

When clicking the green Install button in the “Install From Web” section, the page scrolls down to the “Please confirm the installation by selecting the Install button” section.

This sudden and unexpected movement can create issues for people with vestibular disorders. Either remove the scrolling animation (and replace the functionality with a <dialog> element, or by showing the real installation button at the top) or at least respect user’s prefers reduced motion preferences.

In addition, the keyboard focus is not set to the section the user has scrolled to, so when a keyboard user presses the tab key to go to the next item, they end up at the top after scrolling to the top.

Pressing the “Cancel” button hides the section that has been scrolled to and loses the focus, causing a keyboard user to start from the top.

(See attached video for details. Flashing/scrolling warning.)

The time limit to be logged out due to inactivity logs users out without a notice. Ensure that users can do one of the following actions:

• Turn off: The user is allowed to turn off the time limit before encountering it; or

• Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

• Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times.

Alternatively, extend the time limit to over 20 hours.

When using the J plus other key shortcuts, there is a time limit between hitting one key and the next. This sequence is relatively short and some users with disabilities will find it difficult to press two buttons in short sequence.

Allow users, for example in their personal accessibility settings, to adjust the time limit between the two keystrokes to up to 10 times of the initial length.

In the frontend Cassopeia template, there are no skip links implemented by default. While screen reader and other assistive technology users can navigate by landmarks (banner/navigation/main), this is not possible for keyboard-only users.

When editing an entry, providing a skip link directly to the edit form is useful for efficient keyboard navigation.

Suggestion: Allow keyboard-only users to at least skip the main navigation with a “skip to content” link. You might also want to include a skip link to other important parts of the page, for example to the login form.

10 – Frontend User Forms

When editing a module, the page title is always “Module Settings”, regardless of which module has been selected for editing.

Use descriptive titles like “Main Menu Module Settings”.

13 – Install Joomla

All installation steps have the same title. This can be confusing. Different titles also support people with disabilities when they complete a form by announcing the next step.

Use the fieldset legend to make the <title> element more concrete: “Database Configuration – Install Joomla”

When opening a dialog from the CMS Content menu in the editor, and closing that dialog with ESC or via other means, the focus often gets lost and reset to the top of the page.

The expected behavior would be to put the focus back on the button or menu item that opened the dialog. As the menu items that trigger the dialog are hidden once the dialog is closed, the focus should be returned to the CMS Content button.

Focus indicators are essential as they allow users that use the keyboard or keyboard interfaces to navigate user interfaces efficiently. The indicator style highlights visually where a user is and acts (with the indicators of the previous UI component’s indicators) as a guide through the structure of the site.

01 – Backend Template (Atum)

The Joomla! Admin template, especially in the navigation, focus styles are often undefined. The browser’s default focus styles often do not meet the requirements.

The following graphic shows the “Toggle Menu” button (top) and its hover state (middle) and focus state (bottom):

The focused and unfocused states are the same, so it is impossible for a user to know where they are on the page.

In the buttons on the top of the page, here for example the post installation message, the hover style is a brighter blue while the focus style has a blue outline around the button in Safari. While other browsers have more visible focus styles, relying on the default can make it barely visible, especially on dark backgrounds.

Using the hover style for focus is often not sufficient (and it wouldn’t be here) as hover styles can be more subtle as the user is already following the cursor with their eyes. This is not necessarily true for keyboard focus.

06 – Media Manager

A visible focus indicator is missing or undefined here as well, for example when the Toolbar button is focused, there is no visual indicator.

Suggestion

To implement a general focus indicator that is visible on many different backgrounds, follow Sara Soueidan’s tutorial.

The Article Text field uses a resizable WYSIWYG panel where users can write text or use other functionality to format the content. This field has a resize function that can be operated through the keyboard or by dragging the handle with a pointer device, like a mouse or trackpad.

Some users are unable to carry out these dragging movements, and might not have readily access to a keyboard, for example on mobile. (In addition, the keyboard shortcuts for TinyMCE are fairly complex and difficult to discover.) This is why WCAG 2.2 requires that all dragging movement functionality can be done with a single pointer.

Suggestion: Provide a single pointer equivalent to the resize functionality. This could be a button that allows to increase or decrease the size of the field with one click.

Edit Form Pattern

When having a dropdown with remove option in the interface, that small × icon does not meet the requirements for the size of interactive elements. The minimum size of the element is 24×24 pixels. The small × icon has a size of 20×20 pixels. In addition, the clickable areas overlap.

Suggestion: Ensure that the button is large enough and has space to minimize misclicks. Consider if the remove button is even necessary in all situations. On the Backend Edit Form Pattern page, the Category can be unselected by selecting the Uncategorized option. Also there is a “Remove category” button when the category is set to uncategorized, which seems redundant and when clicked changes nothing.

Backend Options

When setting the time zone, the dropdown also has a “Remove Item” button that removes the time zone and is smaller than 24×24 pixels while overlaying another clickable area. A time zone needs to be set all the time, so when saving the form, the old time zone is restored.

Suggestion: Do not use the “Remove item” functionality for the timezone option.

Frontent User Forms

The same dropdown is used in the front end, here for the position of a module on a page:

Suggestion: Reposition or remove the “remove item” button.

In the login view, the links to various Joomla resources under “Need Support?” are too close together:

Each individual link is just 16.5px high, and the spacing of each list item is 21.5px. This means that the click targets are just slightly too close together. Every target needs to be at least 24px in both, width and hight. Alternatively, targets can be placed further apart to ensure that the links are easy to click.

At 14px text size, set the line height to 24/14 = 1.72 to ensure a clickable area of at least 24px and/or enough space.

When using the Angle Buttons when editing a graphic or photo, when using the keyboard, the rotation is automatically applied using the arrow keys to interact with the (invisible radio buttons.

This results in the keyboard focusing the 0 degree button, when using the arrow key to go to 90, the image automatically flips 90 degrees. Going to the next button does not flip the image 180 degrees from the initial setting, but 180 degrees from the now 90 degree image. Going to 270 degrees then rotates an additional 270 degrees.

Suggestion: Add an apply button and let users select an angle first and then apply it. Alternatively make the buttons buttons instead of radio buttons, so that users have the ability to skip options they don’t want to apply. Also make clear that the buttons add the degrees to the current rotation. Consider displaying somewhere what the combined rotation is.

See the attached video for details.

Changing a setting in a <select> element causes a reload of the page, which is a change of context. Users who use the keyboard to navigate the page need to start from the top of the page again, as do screen reader users.

Instead of reloading the whole page, refresh only the content on the page that changes. If that is not possible and you have to refresh the page, warn users and set the focus to the element that has caused the reload.