Hi all. This is the next idea for simple PR. Who will do it?

Improve accessibility of button Print in Print modal window

In the modal window there is a link Print. This link looks like a button, but it's a CSS styling.

Of course, it should be a button, not a link.
You need a simple patch in the code. Path to file: administrator/components/com_content/Service/HTML/Icon.php

I'm finishing work on the button specification.

Broken links on Github docs

The XX is the area and x.x.x is the criteria code for example 2.4.1

Description of the issue

When I trying to open links eg in the _sidebar file, the 404 error page opens.

Steps to reproduce

Explain step by step how to reproduce the issue or how the feature must work.

1. Go to the accessibility/docs/
2. Open _sidebar.md
3. Click link eg to Checkboxes

1. Alerts are not accessible for colour blind

See: joomla-alert [a11y] #99
@brianteeman closed it for the following reason:

the alerts need a massive rewrite as they are being used completely wrong. It's not if this code is accessible or not but it is where it is being used in the cms. A modal alert is a style it is not necessarily a role=alert - they are not the same thing at all

2. Toolbar - accessibility

See: Toolbar - About accessibility #42

The toolbar is fully accessible to mouse users (and sighted users), but not to keyboard and blind users. There is no way to access the toolbar quickly and directly.
After executing the selected action, the keyboard and blind users does not return to the place from which the action was called. The reason is the unimplemented keyboard support.
See topic below.

3. Efficient navigation on the Backend page for keyboard users

See: [a11y] Provide efficient navigation on the Backend page for keyboard users #442
@brianteeman proposed a solution, but closed PR. See: [4.0][a11y] SkipTo Links for Atum #22149
@brianteeman merged [[4.0][a11y] SkipTo Links for Atum #24142] (joomla/joomla-cms#24142)

4. Admin table - Table option

See: Report: Table option #45

The problem is partially solved by @brianteeman.
The PR was successfully tested, but we did not carry out any verification tests. See: [4.0] [a11y] Table Options #22008

5. Admin table: Drag & drop function is not accessible

Explore of Backend pages type "manager" at Joomla 4 #40
To change the order of items, the administrator can use drag & drop. Unfortunately, users who only use the keyboard cannot perform this task.

6. Admin table: improve accessibility

Explore of Backend pages type "manager" at Joomla 4 #40

@brianteeman presented the concept of a solution. Unfortunately, he closed PR due to lack of tests.
See: [4.0] [a11y] proof of concept for admin tables #21977
Merged. See: [4.0] Sortable Table [a11y] #22404 (thx @brianteeman)

7. No information on the level of nesting of subcategories

Explore of Backend pages type "manager" at Joomla 4 #40
In the category table, the information about the level of nesting of the subcategory is important. Unfortunately, this information is not passed on to screen readers at all.

8. Links to labels

See: [4.0][a11y] Links to buttons #23737
This needs to be checked. It will probably be repaired.

I wrote another fragment of the guide: Validation
Ask for an overview and comments, suggestions.

Please review joomla/joomla-cms#22149

We have prepared a set of web site accessibility tests. Please review, commentary, amendments, etc.

A single page accessibility tests

If you look at any of the tables in the admin eg the table listing the articles you will see that the pagination is inside the table in the tfoot

<tfoot>
	<tr>
		<td colspan="<?php echo $columns; ?>"><?php echo $this->pagination->getListFooter(); ?></td>
	</tr>
</tfoot>

My gut feeling is that this is wrong and that the pagination should be in a <nav> outside of the table

Thoughts?

Hi all. This is the next idea for simple PR. Who will do it?

Improve accessibility of Edit Your Profile form

There are two buttons in the form:

• Submit
• Cancel.

But only one of them is actually a button - "Submit" button. The second one looks like a button, but is a link. Take a look at the source code to see for yourself.

It should be a button, not a link.

When a keyboard user sees a button or screen reader user hears that this is a button, he wants to run it using Spacebar. Unfortunately, Spacebar does not launch the expected action.

What do you think about it? If you agree, don't wait - start working. Prepare PR. You need to fix the file: components/com_users/tmpl/profile/edit.php.

Take a look at our work plan #36

This is our list of tasks for a week: 14 - 20. 03. 2018

1. Review the Website Accessibility Conformance Evaluation Methodology (WCAG-EM)

• Introduction
• WCAG-EM
  Especially review the section: Step 3: Select a Representative Sample

2. On this basis, suggest:

• the list of URL of specific pages (representative samples) under the domain joomla.org, which will be included in the audit.
• the list of typical pages in Joomla3 that will be tested
• list of typical Joomla3 backend pages to be included in the tests
  Do not think that your suggestions may be less professional. It is important that you think and proposes something. Together we will determine what we are going to investigate.

3. Please also take a look at [WCAG-EM Report Tool. Website Accessibility Evaluation Report Generator] (https://www.w3.org/WAI/eval/report-tool/#/)
   We will use this tool during our tests and audits.

4. To all members of the subteam I gave a link to the workflow sheet in Google docs. If you have no access, let me know.
   It also contains access data to the test site of Joomla 3.

I expect from you next week:

• that you are familiar with our action plan,
• that you will make your suggestions for test plan: the joomla.org, joomla3-frontend and joomla3-backend
• that you will create your work card in our workflow control sheet.

Auditing of new media manager

Description of the issue

The team that develops the new media manager needs your input/guidance to make the component fully accessible, thus to conform with the rest of J4

PS ping me in Glip to give people access to the demo site

The Backend login page has passed the accessibility tests (thanks Yannick Berges). Although the page is accessible, several issues need to be considered and possible adjustments should be made.

Inadequate title of page

Page TITLE element does not describe its function or purpose. The title of the page shall be 'Administrator'. In fact it is the "Login page" (or "Login to the Backend").
See:

• 2.4.2 Page Titled - Level A. Web pages have titles that describe topic or purpose.
• G88: Providing descriptive titles

Redundant and incorrect tabindex attribute

A positive tabindex value is present in two input field and in button element. Tabindex values of 1 or greater specify an explicit tab/navigation order for page elements. Because it modifies the default tab order, cause confusion, and result in decreased keyboard accessibility, it should be avoided.
How to fix it
If the natural tab order is already logical, remove the tabindex. Otherwise, consider restructuring the page so that tabindex is not needed. If tabindex is maintained, ensure that the resulting navigation is logical and complete.
See:

• 2.4.3 Focus Order - Level A

Fieldset missing legend

A fieldset legend presents a description of the form elements within a fieldset and is especially useful to screen reader users. A legend should be provided when a higher level description is necessary for groups of form controls.

It is required that the fieldset and legend are used conjuction. A fieldset cannot be used without a legend and visa versa. (by Steve Faulkner, The Pacciello Group)

How to fix it
If a higher level description is necessary for the user to understand the function or purpose of the controls within the fieldset, provide this description within the legend. If this description or grouping is not necessary, the fieldset should probably be removed.
See:

• 1.3.1 Info and Relationships - Level A
• 2.4.6 Headings and Labels - Level AA
• 3.3.2 Labels or Instructions - Level A
• Fieldsets, Legends and Screen Readers

The page has no main landmark

Content should be contained in a landmark region. This is not a requirement for accessibility, it is good practice. The page should have at least a main landmark.
See:

• 1.3.1 Info and Relationships - Level A
• Content should be contained in a landmark region
• There must only be one main landmark to navigate...

Ask for comments, suggestions or patches and PR submissions.

Research request: Tags

Has anyone time to review this code about tags
@dgt41 needs requirements for this functionality
Can we do a research on this?

https://codepen.io/dgt41/pen/YxdNpw?editors=0010

When we have tested en have done research we can make a documentation.

sharing accessibility extensions (menu, plugin tool, video player)

Dear JAT’ers 😊
Our dear (beloved) Yair has a question and an proposal on which we need to discuss or just give an answer.
So I did some research and have my answers to Yair about this topic.
But first I like to share this with you so you can think and discuss about this.

@ylahav said that he has some accessibility extensions which he want to share within Joomla
Question is, can this be part of Joomla 3 core or not?
Can it be maintained within Joomla?

@ylahav can add if I forgot something to mention.

The accessibility extensions that Yair wants to give to the community are:

1. accessibility plugin (today baccessability)
   a. put a float toolbar on the left / right side of the screen
   b. the toolbar give the ability to:
   i. increase / decrease font size
   ii. dark / light contrast
   iii. underlines under all links
   STATUS: this plugin is a conversion of the module I wrote and can be found in GITHUB. It was rewritten in order to simply the definition and configuration and to have it as a pure JavaScript (no jquery)
2. accessibility menu plugin (today bmenu)
   a. add 'aria' attribute to menu
   b. allow keyboard navigation
   c. pure JS
   STATUS: pass @zwiastunsw Stephan test. can be used.
   Needs: some refinement to simply configuration
3. accessibility audio / video player (based on JS player which is already accessible) (today bplayer)
   a. has all needed features: subtitle, subscript etc. + keyboard navigation
   STATUS: tested by @zwiastunsw Stefan

Main tasks

The Audit & Tests subteam will perform 4 tasks for the coming months:

• audit accessibility of joomla.org in accordance with the procedure WCAG-EM
• audit accessibility of the frontend Joomla3 with example data,
• audit accessibility of the backend Joomla3
• tests of Joomla4 at the request of the production team.

Goals

Audit accessibility of joomla.org

1. Preparing a complete accessibility report according to the WCAG-EM Report Tool
2. Report errors and faults detected on the joomla.org domain pages

Audit accessibility of the Frontend Joomla3

1. Pointing out the current Joomla frontend accessibility issues.
2. Sending the issues list to the Implementation & Development subteam

Audit accessibility of the Backend Joomla3

1. Pointing out the current Joomla backend accessibility issues.
2. Preparing the guidelines for J4 accessible backend.

Tests of Joomla4 elements

1. Provide feedback to the production team.

We can, of course, discuss and improve this plan.
But I would like us to act immediately.
That's why see more #37 (Audit & Test Subteam Tasks 14.03.2018 - 20.03.2018)
Enter your comments on the plan here.

After our discussions at JAB where I explained that you cannot copy any text from anywhere unless it is expressly stated by the source that you can copy it and that the copied text is correctly quoted and attributed.

Today I saw a pull request being merged #38 and can see that the text is a direct copy of other peoples text - specifically from the w3c

they have very specific rules and guidance when copying their documentation
https://www.w3.org/Consortium/Legal/2015/doc-license

it is great that you want to contribute to joomla but we just cant take other people's work without permission or credit.

please note that as this is a public repo we (joomla) are now in breach of copyright etc

@marcodings @wilsonge @armenos

Do we need a label "accessibility"? Everything here is about accessibility.

I wrote another fragment of the guide: Color tools – generators, simulators, checkers

Ask for an overview and comments, suggestions.

I think we should describe in a concise document what Joomla Accessibility Team is doing, for which the JAT is responsible.
Here are two of my proposals for such a document. I invite you to the discussion. I apologize for my English. I hope that we will find better wording in the discussion.

What is Joomla Accessibility Team doing?

• We define accessibility requirements for Joomla!
• We analyze Joomla! accessibility and initiate improvements
• We analyze the accessibility of websites in joomla.org domain and initiate the elimination of barriers
• We assess the compatibility of Joomla extensions and templates with accessibility requirements.
• We help developers, designers and webmasters understand accessibility
• We help extension and templates designers to solve accessibility problems
• Let us evaluate Joomla new features in terms of accessibility
• We maintain a list of Joomla extensions and templates that meet the accessibility requirements.
• We prepare accessibility documentation of Joomla UI components
• We create guides on creating accessible content, extensions, and templates.

Responsibilities Joomla Accessibility Team:

• Define accessibility requirements for Joomla!
• Analysing Joomla accessibility and initiating improvements
• Analyzing the accessibility of sites in joomla.org domain and initiating elimination of barriers
• Helping extension designers and templates to solve accessibility problems
• Assessing the compatibility of Joomla extensions and templates with accessibility requirements
• Help developers, designers, and site developers to understand accessibility
• Assessing Joomla's new features in terms of accessibility
• Maintenance of Joomla extension and templates lists that meet accessibility requirements
• Preparation of documentation for the accessibility of Joomla UI components
• Developing guides on creating accessible content, extensions, and templates

What next steps?

Introduction

We want to encourage and mobilize designers to make Joomla extensions and templates as accessible as it can be.
We also want to make sure that Joomla users know whether the extensions or templates meets accessibility requirements.

Our goal is to have the Joomla 4 and extensions or templates for Joomla4 compliant with accessibility requirements, ready to build accessible sites.

We are considering a proposal for designers to declare compatibility of WCAG 2.0 extensions placed in Joomla Extension Directory.

Drupal has its own #D8AX hashtag (Drupal 8 Accessibility eXperience). Wordpress has a tag Accessibility Ready for their themes.

I propose the creation of a badge "Joomla for all ".

Rules:

1. The developer can mark his extension or template with a J4A badge.
2. The developer includes the following statement on the project page, including Joomla Extension Directory or the planned Joomla Template Directory:

We have tried to make this extension/template as accessible for all as possible. If you find any defects, let us know. We will fix them.

where

• the words as accessible for all as possible are a link between the "Joomla Accessibility Code" (or Accessibility Statement).
• the words let us know are a link to the contact form with developer or him issue tracker.

3. The developer may extend the declaration with a list of accessibility features and evaluation tools.
4. The JAT will carry out regular audits of the accessibility of extensions and templates and publish reports in the Joomla! Community Magazine.

What do we have to do?

1. Developing the Joomla Accessibility Code
2. Developing badge
3. Popularize the badge

Please discuss!

Review process

• Scope of review
  • name of UI elements: Table option
  • date of review: 21/07/2018
• Reviewers: Stefan Wajda
• Evaluation environment:
  • Windows 10,
  • Chrome 67.0.3396.99
  • Methods and tools
    • Tools: aXe, Lighthouse, NVDA
    • Methods: code inspection, testing keyboard only, testing with screen reader

Result and recommended action

Summary of results

The sorting and filtering functions provided by the tool are accessible. However, a few of problems have been identified that may result in inaccessibility.

Strengths

All sorting and filtering options are accessible from the keyboard..

Failures and recommendations

1. The ‘select’ elements do not have corresponding labels

The select lists do not have correspondingly associated labels. The function or purpose of the lists can not be presented to screen reader users. Some users may also have problems understanding the purposes of the lists. The functions of some lists can be deduced by users from the name of the first option ('Select Category', 'Select Status', 'Select Access', etc.). But in a few cases there is no such value describing the purpose of the list: (1) a list limiting the number of items per page, (2) a list ‘Select location’ on pages: “Modules manage” “Language installed”, “Templates: Styles”.

• Recommendation:
  • Add labels for users of screen readers (hidden from sighted users - ‘sr-only’)
  • Add first option value: “- Select Location -” and “- Item per page” for sighted users
• Success Criteria:
  • 1.3.1 Info and Relationships (Level A)
  • 2.4.6 Headings and Labels (Level AA)
  • 3.3.2 Labels or Instructions (Level A)
• Suggested techniques:
  • H44: Using label elements to associate text labels with form controls
  • G131: Providing descriptive labels
  • ARIA6: Using aria-label to provide labels for objects
  • ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
  • ARIA16: Using aria-labelledby to provide a name for user interface controls

2. Select must not change context

When a keyboard-only user uses the Escape key on an option that has a focus, the page is automatically reloaded. Similarly, when the screen reader user changes a selected option in the list is collapsed using the arrow keys, the page is automatically reloaded.

Select elements with onchange event handler must not automatically change the user's context when keyboard focus moves between options.

User's can become disoriented if the focus changes cause unpredictable actions.

When the user is using the keyboard to explore select box options, the focus must stay on the options, until the user selects one of the options.

See: FAE - select must not change context

• Recommendation: Do not use onchange event handlers on select elements. Use selections should be made using the enter key.
• Success Criteria:
  • 3.2.2 On Input (Level A). Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
  • 2.1.1 Keyboard (Level A)

3. No labels in multiple-select lists

Multiple-select lists are used on the Article manager page. The user does not see the description of these lists as they are expanded. Screen reader users hear neither list description nor list option names.

• Recommendation:
  • Add labels for users of screen readers (hidden from sighted users - ‘sr-only’)
  • ????
• Success Criteria:
  • 1.3.1 Info and Relationships (Level A)
  • 2.4.6 Headings and Labels (Level AA)
  • 3.3.2 Labels or Instructions (Level A)
• Suggested techniques:
  • H44: Using label elements to associate text labels with form controls
  • G131: Providing descriptive labels
  • ARIA6: Using aria-label to provide labels for objects
  • ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
  • ARIA16: Using aria-labelledby to provide a name for user interface controls

Appendix: Keyboard interaction

• Tab / Shift+Tab:
  • moves focus from the previous/next interactive element to a button when it is collapsed (all list are collapsed)
  • when the lists are expanded, moves focus between the lists
• Enter:
  • when the focus is on a collapsed button, expand the lists
  • when the focus is on a collapsed list, expand the list
    Note: If none of the options are selected before the listbox receives focus, the first option receives focus. Otherwise, the currently selected option in the list receives focus.
    when the focus is on the selected option, activate this option
• Space:
  • when the focus is on a collapsed button, expand the lists
  • when the focus is on a collapsed list, expand the list
• Arrow Up / Arrow Down: moves focus to the previous/next option
• Home / End: moves focus to the firs/last option
• Type a character: moves focus to the next/previous option with a name that starts with the typed character.
• Quickly type multiple characters: moves focus to the next/previous option with a name that starts with the string of characters typed
• Backspace: remove an option from the multiple-choice list
• Escape: collapses the listbox without selecting the currently focused option

We should deal with the accessibility of joomla.org. Step by step. We do not have enough strength and resources.

Let us consider how to fulfill our duty. Let us define a road map. I think there are a few elements that should be included.

1. Examine the current state of play of site accessibility procedures:

• Are there any procedures?
• Have they been written down somewhere?
• Have you identified who is responsible for the accessibility of sites?
• Who oversees? What is supervision? What is the supervision mode?
• Have you set the accessibility monitoring mode?
• Have evaluation procedures been defined?

I think that the answer to all the questions is: No. But we should examine this and write a report.

2. Perform an audit of website accessibility under the joomla.org domain.
   There are 16 sites in the domain joomla. org.

• How to conduct an audit?
• Should all parties be audited?
• Who will do it?
• Will our team ever be able to perform such an audit?
• Should an external audit not be outsourced?

3. After evaluating the sites, outline for the Webmasters Team the changes that would be required to retrofit the site for accessibility.

4. Developing together with the Webmasters Team procedures for monitoring and maintaining accessibility joomla.org sites.

My proposition:

Project: Mini Joomla accessibility test.

Two goals:

1. Test and evaluate the basic features of Joomla - common features such as search, login, and typical pages such as blog, category list, and more.
2. Involve more volunteers to test the accessibility of Joomla.

How?

Every week we announce a task: What to test? We give instructions on how to test. We give the report template. We wait 7 days for the test reports. Then we come up with a summary. If the reports are not enough, we extend the testing deadline.

Expected effects:

1. We will create and describe testing procedures.
2. We will provide everyone with an opportunity to actively participate in JAT work.
3. We will receive test reports in a variety of environments (browsers, operating systems, assistive technologies).
4. We will expand our team - we will get new volunteers.
5. We will get rich material to evaluate the accessibility of Joomla.

What do you think of this idea?

Hi all. This is the next idea for PR. Who will do it?

Improve accessibility of Registration form

There are two buttons in the registration form:

• Register
• Cancel.

But only one of them is actually a button - "Register" button. The second one looks like a button, but is a link. Take a look at the source code to see for yourself.

The "Register" button works perfectly. But the false Cancel button is confusing.

When a keyboard user sees a button, he wants to run it using Spacebar. Unfortunately, Spacebar does not launch the expected action.

The screen reader user hears that this is a link. Unfortunately, they can't hear where this link leads.

Using "Cancel" redirects you to the homepage. This behavior is unexpected. It causes an unexpected change of context. When I use the button, I expect the cursor to return to the place where the action was called.

In my opinion:

• The current link "Cancel" should be changed to a button.
• The only action that the Cancel button should launch is the Reset action. That's why I think it should be a Reset button.

What do you think about it? If you agree, don't wait - start working. Prepare PR.

Web accessibility means designing and developing your website so that people with disabilities can perceive, understand, navigate, and interact with, and contribute to, the Web.

I really hate this description. Accessibilty should be about ensuring that everyone can use the web

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
— Tim Berners-Lee, W3C Director and inventor of the World Wide Web

The toolbar is a key element of the Joomla Backend user interface. It contains a set of tools that allow you to perform various operations on content items. Therefore, the administrator should:

• get quick and direct access to the toolbar from anywhere in the workspace
• after performing the action, return to the place from which the action available in the toolbar was called
• move between the options of the toolbar with the arrow keys
• run actions optionally with mouse or default keyboard key (Space - actions, Enter - links).

The accessibility requirements that a good toolbar should meet are precisely defined in WAI-ARIA Authoring Practices 1.1.

Results of current tests

I tested in Windows 10, with NVDA 2018.2.1 and ChromeVox.

1. The toolbar is fully accessible to mouse users (and sighted users), but not to keyboard and blind users.
2. There is no way to access the toolbar quickly and directly. To access the toolbar, the keyboard user must use the Tab key to visit all the controls that are located before the current cursor position or after the current cursor position, one by one. To fix this problem, we can
   -- (1) create a new special navigation element on the Backend pages,
   -- (2) use the accesskey attributes.
3. Moving between buttons requires the use of Tab or Shift+Tab instead of the default arrow keys. The Tab or Shift+Tab keys should move to the next/prev control item. To correct this problem, we must implement correct keyboard support, as described in the WAI-ARIA Authoring Practices 1.1.
4. After executing the selected action, the user does not return to the place from which the action was called. The reason is the unimplemented keyboard support.

In addition, the screen reader announces the role and label of the toolbar, which sounds the same (toolbar). This is not a good practice. It's best to use a label that describes the purpose of the toolbar, e.g. "Action menu".

There are several open accessibility pull requests that it would be great if you could do a quick test so that we can merge them and move forward.

joomla/joomla-cms#21865
joomla/joomla-cms#21724
joomla/joomla-cms#21608
joomla/joomla-cms#21604
joomla/joomla-cms#21559

joomla-projects/custom-elements#99

@dgt41 asked for accessibility tests:
https://joomla-projects.github.io/custom-elements/bootstrap-demo.html
Ask for test results and comments here.

Who likes to do what?

For example
I’ve asked Justyna to help me with organization and support me somehow.
But she can tell which areas she likes to be active, like organizing our meetings, etc.

I know Yair likes to develop, so we know he want to make extensions, like menu, video player, content fixer or a11y issue marker. We will discuss on this in another topic.

Feel free to say what are you expertise fields and what you do like to do and what you could do.

Every member can be active to make new comers feeling welcome to our project, etc.

I'm finishing work on the breadcrumbs specification.

Please review

• in terms of substance (please: @armenos, @chmst, @uglyeoin, @seenee, @moje-s, @ylahav)
• in terms of language (please: @tarotray )

@dgt41 asked for accessibility tests:
https://joomla-projects.github.io/custom-elements/bootstrap-demo.html
Ask for test results and comments here.

Review process

• Scope of review:
  • name of screen: System information
  • date of review: 19/07/2018
• Reviewers: Stefan Wajda
• Evaluation environment:
  • Windows 10,
  • Chrome 67.0.3396.99
• Methods and tools
  • Tools: aXe, Lighthouse, NVDA
  • Methods: semi-automatic and automatic evaluation, manual evaluation, usability testing, keyboard only, assistive technology (screen reader)

Result and recommended action

Summary of results

The page is for information purposes only. All informations are accessible, but a number of issues have been identified that can cause problems. Repairing them can improve user experience.

Strengths

The data tables are of simple structure and are correctly marked.

Failures and recommendations

1. Admin menu

The menu module was not evaluated as it is working on an improved version. However, please note that in the current menu there are several internal links named "collapse1", "collapse3", "collapse5", "collapse7", but no anchor exists with that name. However, there are anchors: "collapse2", "collapse4", "collapse6", "collapse8".

2. This is not a form

The main content of this page is covered by the form tag. It does not contain any controls - no fields, no buttons.

• Recommendation: Consideration should be given to removing unnecessary form tag.
• Success Criteria: 4.1.1 Parsing (Level A),
• Suggested techniques:
  • G192: Fully conforming to specifications
  • H88: Using HTML according to spec

3. Redundant fieldset tags

The data tables are located inside the fieldset tag. The fieldset tag is intended for grouping the form controls, but the data table does not contain any form controls. The use of fieldset tags is incorrect and may be confusing.

• Recommendation: remove the redundant fieldset tags.
• Success Criteria: 4.1.1 Parsing (Level A),
• Suggested techniques:
  • G192: Fully conforming to specifications
  • H88: Using HTML according to spec

4. Headers instead of legend tags

Since the fieldset tags must be removed, the associated legend tags must also be removed.

• Recommendation: replace them with an h2 tags.
• Success Criteria: 4.1.1 Parsing (Level A),
• Suggested techniques:
  • G192: Fully conforming to specifications
  • H88: Using HTML according to spec

5. Redundant tfoot element

The tables contains an empty tfoot element. It is recommended to deleting them.

6. Toolbar - buttons marked as links.

The two buttons in the toolbox are marked as links, although semantically they are buttons (buttons: Download as text, Downloads as JSON). The link is not a valid semantic tag in this case. It will misinform the blind user. A screen reader user expects to connect to a different page or location on a page, not an action.

• Recommendation: change its to button (Use buttons to signal clickable actions, such as “download,” “sign up,” or “log out”).
• Success Criteria: 4.1.1 Parsing (Level A),
• Suggested techniques:
  • G192: Fully conforming to specifications
  • H88: Using HTML according to spec
    See: Links vs. Buttons in Modern Web Applications

7. Toolbar - insufficient contrast

Button Help has insufficient contrast at this conformance level. Expected a contrast ratio of at least 4.5:1, but text in this element has a contrast ratio of 3.04:1.

• Recommendation: change background to #008297.
• Success Criteria: 1.4.3 Contrast minimum.
• Suggested techniques: G18: Ensuring that a contrast ratio of at least 4.5:1

My proposal for the Joomla Accessibility Team structure
I think that in the future Joomla Accessibility Team should be composed of three subteams:

1. Advisory Subteam.
   Task: advising on accessibility, creating guides, helping in forums
2. Audit & Testing Subteam.
   Task: Testing and evaluation of Joomla, Joomla elements, Joomla extensions, Joomla templates and Joomla.org websites
3. Implementation Subteam:
   Task: Design and development of accessibility improvements, extensions, etc.
4. Promotion Subteam:
   Task: Promotion of JAT activities and initiatives, promotion accessibility issues among Joomla extensions developers, etc.

What do you think about this?

The documentation is still under construction.
26.01.2018 and 22.02.2018 JAT Leadership met to build JAT organization and workflow documentation. We invite you to share your ideas.

Joomla Accessibility Team meeting

Agenda

1. Team management
   a) Team structure
   b) The team management composition
   c) Team management meetings
   d) Work rules
   e) official communication/work channels
2. Overview of the work state - started and unfinished topics

Team structure

In September, we presented a team structure proposal, according to which Joomla Accessibility Team consists of three components:

1. Advisory Subteam
2. Audit & Testing Subteam
3. Implementation Subteam.

We decided to add also
4. Accessibility Promotion Subteam

The point is not to create new beings, but to provide everyone with a clear opportunity to determine their place in the team and to ensure the efficiency of managing the entire team.

The team will have a structure when

• there will be a group of people who will be assigned to subteam (at least 3, we hope)
• subteam will have an official leader/coordinator

Subteam coordinator duties:

• subteam organization
• subteam meetings organization
• team leaders meetings participation

Idea:

• JAT members declare to belong to at least one of 4 subteams, declarations deadline: 01.03.2018.
• during next week (02 - 08.03.2018) members of each subteam will meet to choose a subteam coordinator. The dates of the meetings will be set with Justyna Michallek.

Team hierarchy

team leader, team leader assistant, subteam leaders (coordinators).

Meetings

Idea:

There must be a fixed date for team and subteams meetings. The date should not be changed (changes disorganize work).
The team leadership should meet:
*at least once a month at "official" meetings, summarizing the work in the previous month (report of subteams on achievements) and defining the work plan (tasks) for the next month; these meetings should be reported on joomla.org
*once a week or once two-weeks at "working" meetings, to consider and decide on current issues (discussing development directions, planning specific tasks, summarizing them).

Idea:

"Working" meetings will take place every week at Thursday at 4:30 pm UTC+1
"Official" meetings will always take place in the first Thursday of the month at 4:30 pm UTC+1

The subteams should meet:
*once a week or once two-weeks at "working" meetings, to consider and decide on current issues (discussing development directions, planning specific tasks, summarizing them).

Workflow

• everyone is a member of at least one subteam
• ways to become the JAT contributor
  • notification
  • sending the JAT Application: http://bit.ly/JAT-application
  • joining the team
  • working for at least 5h/month
• ways to become the JAT team member
  • express the will of membership
  • in the next three months give at least 15h/month (3h/week) of work

Removal from the team / suspension of membership
................................................
.................to prepare.....................
................................................

Membership criteria

Guest:

A person who wants to contribute to the improvement of Joomla accessibility and has applied to join the team.
Duration: 1-2 months
Tasks:
*familiarize with the JAT working rules and tools (Glip, Github, JDocs, Activity Report)
*subteam membership declaration
*familiarize with chosen subteam achievements, work state and roadmap.
Personal development: learning the basics of web accessibility (e. g. https://w3c.github.io/wai-website/tutorials/)
Contribution: work for the chosen subteam 5 hours in total
Permissions: Access to the Glip JAT Members channel and chosen subteam Glip channel

Contributor:

Overview: to prepare

Tasks
*sending JAT Application
*subteam membership
*reporting to subteam leader / coordinator
*defining personal development program related to chosen subteam
Contribution: minimum 1-2 hours per week/6 hours per month, monthly summarized
Permissions: Access to the Glip JAT Members channel and chosen subteam Glip channel
Rights: to prepare

Member:

Overview: to prepare

Tasks
*subteam membership
*reporting to subteam leader / coordinator
Contribution: minimum 3 hours per week/12 hours per month, monthly summarized
Rights: to prepare

Official communication/work channels

• GLIP
• GITHUB
• Volunteers portal (https://volunteers.joomla.org/)

The goal of this task is to detect accessibility problems on Backend pages such as User manager, Menu item manager, Article manager, Category manager, etc.
We do not impose evaluating methods on anyone. Do it as you can.

• Examine the selected pages.
• Report the results of your tests and analyses here.
• Discuss the issues raised in the reports.

At what stage are we? What do we need?

Elements must have sufficient color contrast
#toolbar-help
To solve this violation, you need to:
Fix the following:
Element has insufficient color contrast of 3.04 (foreground color: #ffffff, background color: #17a2b8, font size: 11.3pt, font weight: normal). Expected contrast ratio of 4.5:1
Related node:
#toolbar-help

To solve this violation, you need to:
Fix the following:
Element has insufficient color contrast of 3.04 (foreground color: #ffffff, background color: #17a2b8, font size: 8.4pt, font weight: bold). Expected contrast ratio of 4.5:1
Related node:
.badge-info

Form elements must have discembile text 20 elements
Issue description
Ensures every form element has a label
Impact: critical
Element location
<input type="checkbox" id="cb0" name="cid[]" value="2" onclick="Joomla.isChecked(this.checked);">
To solve this violation, you need to:
Fix at least one (1) of these issues:
aria-label attribute does not exist or is empty
aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty or not visible
Form element does not have an implicit (wrapped)
Form element does not have an explicit
Element has no title attribute or the title attribute is empty

Links must have discernible text
Element location
a[data-order="a\.lft"]
Element source
<a href="#" onclick="return false;" class="js-stools-column-order hasPopover" data-order="a.lft" data-direction="DESC" data-name="" title="" data-content="Select to sort by this column" data-placement="top" data-original-title="Ordering">

To solve this violation, you need to:
Fix at least one (1) of these issues:
Element does not have text that is visible to screen readers
aria-label attribute does not exist or is empty
aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty or not visible
Element's default semantics were not overridden with role="presentation"
Element's default semantics were not overridden with role="none"
And
Fix the following:
Element is in tab order and does not have accessible text

Checkbox inputs with the same name attribute value must be part of a group
Ensures related <input type="checkbox"> elements have a group and that the group designation is consistent
Impact: critical
Element location
#cb0
Element source
<input type="checkbox" id="cb0" name="cid[]" value="2" onclick="Joomla.isChecked(this.checked);">

To solve this violation, you need to:
Fix at least one (1) of these issues:
All elements with the name "cid[]" do not reference the same element with aria-labelledby
Element does not have a containing fieldset or ARIA group
Related nodes:
#cb1
#cb2
#cb3
#cb4
#cb5
#cb6
#cb7
#cb8
#cb9
#cb10
#cb11
#cb12
#cb13
#cb14
#cb15
#cb16
#cb17
#cb18
#cb19

Form elements should have a visible label
Ensures that every form element is not solely labeled using the title or aria-describedby attributes
Impact: serious
Element location
input[name="checkall-toggle"]
Element source
<input type="checkbox" name="checkall-toggle" value="" class="hasTooltip" title="Check All Items" onclick="Joomla.checkAll(this)">

To solve this violation, you need to:
Fix the following:
Only title used to generate label for form element

The skip-link target should exist and be focusable
Ensure all skip links have a focusable target

Impact: moderate
Learn more
Element location
a[href$="#collapse1"]
Element source
<a class="collapse-arrow" href="#collapse1"><span class="fa-fw fa fa-file-text"></span><span class="sidebar-item-title">Content</span></a>

To solve this violation, you need to:
Fix the following:
No skip link target

There are a few people. This is not enough to fulfill our mission. We need to build a team. And in order to do this, we must have a vision of the team.
Expansion of the JAT

1. Define our responsibility. I have made a proposal. Responsibilities need to be discussed and agreed upon.
2. Define a index our tasks. The method of defining the scope of the team's responsibility is to draw up an index of the team's tasks, the work we intend to do.
3. Define the target group structure. I have presented a preliminary structural design. Once we have defined the tasks of the team, we should assign them to the subteams.
4. Share responsibility for managing team matters (I am thinking of such tasks as: work planning, working with staff, maintaining team resources - Github, Portal Accessibility, cooperation with other teams, promotion of team work.)
5. Define procedures for working with other teams (With whom? To what extent? Who is responsible? )
6. Define a system of work with the staff (positioning, introduction, support, mentoring, accounting)
7. Establish a plan for the promotion of the JAT.

Any ideas? Suggestions for action?

Component: com_content, view: List all categories (frontend, Joomla3)

The page content is a list of all categories. You can also display the description and categories illustrations. Next to the category header, you can also display a badge with information about the number of articles in each category. Category title is a link to a page with a list of all categories in the nested category or list of articles in a category.

1. Screen reader user is not informed that this is a list of items / nested list of items.
2. Subcategories are displayed on hidden (collapsed) panels. Users are not informed that these are drop-down panels and they also don’t receive the status (expanded or collapsed).
3. When using tab, the focus disappears in the non-expanded panels.
4. Graphical links (plus and minus icons) are used to expand and collapse the panel. Functionally, these should be buttons, not links. Blind persons receives the message that this is a link but without the purpose of the link.
5. The title of the parent category is a link to a category page - unnecessarily it moves the users to the other page instead of expanding a content panel.
6. The header structure is incorrect. Category titles are marked with H3 tag, titles in subcategories are also covered by H3, which does not reflect the structure of content. In addition, the header H3 follows the header H1 with the title of the page - there is no heading H2.
7. Next to the category name there is an information about number of articles published in this category. Is displayed with a use of the badge. According to Bootstrap 3 specification

• Badges are used to display numbers, not text. In the code of this element there is also the text: ‘Number of articles’. Badges must be empty (only under this circumstance, Bootstrap will automatically hide the badge where there are no articles published in the category - except for IE8, because it lacks support for the :empty selector. Note: This can be omitted - in Bootstrap 4 the badge can contain both text and numbers.
• The "Number of articles" label is unnecessarily repeated - once, on the badge and, the second time, in the tooltip.

8. When there are no articles in a category that contains subcategories, the label "Number of Articles: 0" is displayed - this is incorrect because there are still articles in subcategories. Instead of the "Number of articles" label, the label "Number of subcategories" should be displayed.

9. Category illustration: suggestion to add class CSS attribute (for ex. category-image).

You will get the same page view:

• Contacts component – view List all categories
• Newsfeed component – view List all categories

@dgt41 asked for accessibility tests:
https://joomla-projects.github.io/custom-elements/bootstrap-demo.html
Ask for test results and comments here.

We use icon fonts in many places. In this post I propose the consistent use of three patterns of embedding the font icons to ensure their accessibility.

There are basically two types of icon fonts:

• stand-alone icons that convey meaning, semantic icons
• decorative icons illustrating the accompanying words.

Decorative icon

Decorative icons express the same meaning as the accompanying words. We use them to visually enhance the meaning of the illustrated words. If we remove them from the page, users will still fully understand the content and will be able to use the page. Such icons do not have to be announced to users of screen readers. We should hide them from screen readers.
To hide the icon font from screen readers, we use the aria-hidden="true" attribute. Add it to the tag with the icon font.

For example:

<span class="icon-*" aria-hidden="true"></span>

Stand-alone icon

Stand-alone (semantic) icons convey meaning by themselves. They cannot be removed from the page without losing meaning or functionality. Since some users may not see the graphic symbols, we should pass their content in an alternative text. This is an elementary accessibility requirement specified in WCAG 2.1 by success criterion 1.1.1.
Stand-alone icons can be interactive elements, e.g. buttons, switches, links and "normal", non-interactive content elements.

Non-interactive icons

If the icon is not an interactive element:

• hide the icon from the screen readers using the aria-hidden="true" attribute,
• provide a label for sighted users of the mouse using title attribute,
• provide alternative text visible only to screen readers using sr-only class.

For example:

<span class="icon-*" aria-hidden="true"  title="Meaning of the icon"></span>
<span class="sr-only">Meaning of the icon</span>

Interactive icons

If the icon is an interactive element:

• provide the accessible icon name to the screen readers using the aria-label="ActionName" attribute.
• hide the icon from the screen readers using the aria-hidden="true" attribute.
• provide a label for sighted users of the mouse using title attribute,

Note that in this case you do not have to create a hidden element with alternative text only for screen readers.

For example:

<button class="icon-btn" aria-label="Action" onclick="action">
   <span class="icon-*" aria-hidden="true" title="Action"></span>
</button>

<a href="location" aria-label="Location name">`
 <span class="icon-*" aria-hidden="true" title="Location name"></span>
</a>

Note that the title attribute with label is added to the tag with the icon hidden from the screen readers, as opposed to the aria-label attribute. As a result, screen readers do not repeat the label twice.

Digression

In the discussion on PR Make ActionButton Featured accessible #23718 I withdrew from the suggestion to add a title attribute to provide an accessible name for sighted users.

The PR author's argument that the meaning of the icon would be understandable from the context (column name) seemed convincing.
After thinking about it, I have to say that it was a wrong decision.

The title attribute is necessary (or any other way of providing alternative text for sighted users). Otherwise, the meaning of the icon may be incomprehensible to some users. No alternative text violates the Success Criterion 1.1.1 Non-text Content:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose.

Note: The problem can be solved using tooltips: https://codepen.io/dgrammatiko/pen/eGELjo

See:

• Font Awesome & Accessibility. Make your icons awesome for all of your users

About title attribute see:

• The Trials and Tribulations of the Title Attribute
• Don't Rely on the Title Attribute for Accessibility

The breadcrumb generated in Joomla4 basically does not cause problems of accessibility.
The set of links is structured using an ordered list. This is a good choice because the ol tag is appropriate for presenting the hierarchical structure of the breadcrumb (the order of elements in the breadcrumb is important).

The code for the breadcrumb has been supplemented by a nav tag with the attributes aria-label="[module name]" and role="navigation" (See: [4.0][a11y] Add landmark to breadcrumbs #23685.)

Nav tag defines the breadcrumb area as a landmark, more precise navigation area. The aria-label attribute provides an accessible name for the landmark. The use of the aria-label attribute is appropriate, because there can be more than one landmark of this type on the page.

The role="navigation" attribute defines the same property as the nav tag. Since the nav tag has an implicitly entered navigation role, adding this role is redundant. However, this role has been added because Joomla has chosen to support IE11 (IE11 does not support new HTML5 tags, but supports ARIA attributes).

What else can be improved?

Add aria-current attribute

The aria-current attribute is used inside a set of related elements. The screen reader announces its value (e.g. Current page). The attribute can also be used as a selector to define the display style of the current position in the item set. If the element representing the current page is not a link, aria-current is optional.

Let's consider whether it should be a link? Would that be good for accessibility?

In my opinion, it should be a link. Just like in the menu, the active item is a styled link.
When the screen reader user navigates only between links, he will hear that the last item is a link and that it indicates the current page. If it is not a link, the screen reader user will hear the name of the last element of the breadcrumb only if he listens to the entire page.

Let's consider whether this item should have an aria-current attribute?

In my opinion yes. Regardless of whether it will be a link or not. Because the user of the screen reader may receive additional important information. It will hear information that the visually impaired user can read from the screen. This is good for accessibility.

Remove option Text separator

The Text Separator option allows the user to define a custom visual separators between breadcrumbs items. If the user does not define his own character, he default separator defined via css will be used.

When the user adds his own text separator, e.g. a slash, the screen reader will announce it. To prevent the screen reader from announcing visual separators between links, they should be added via CSS. Of course, we can hide these elements using the aria-hidden attribute, but this requires additional HTML code, which is not currently available.

We know that users sometimes have strange ideas. According to ATAG requirements, we should prevent the creation of inaccessible content and warn users when accessibility is at risk.

If we leave the possibility to define our own visual separator, we have to add an additional code or warnings for the administrator. If we remove this option, we will simplify the code, simplify the configuration of the module (number of options) and avoid the situation that the user will deteriorate accessibility.

What do you think about it? What is your opinion?
If you agree with me, don't wait - start working. Prepare and report PR.

Resources

• WAI-ARIA Authoring Practices 1.1 - 3.4. Breadcrumb
• Breadcrumb design pattern example
• Accessible Breadcrumb Navigation Pattern by Scott O'Hara
• Using the aria-current attribute by L. Watson

I'm working on a specification.

Please suggestions, comments.

Scope of review:

• name of screen:
  • Modules: New/Edit Articles - Category
• date of review: 2019/02/12
• reviewers: Stefan Wajda
• Evaluation environment:
  • Windows 10,
  • Chrome 72.0.3626.81, Firefox/65.0
  • Apache 2.0 server (online)
• Methods and tools
  • Tools: aXe, Lighthouse, tota11y, ANDI, NVDA v. 2018.2.1
  • Methods: semi-automatic and automatic evaluation, manual evaluation, usability testing, keyboard only, assistive technology (screen reader)

Result and recommended action

Summary of results

The screen "Modules: New/Edit Articles - Category" contains 9 collapsible tab panels: Module, Menu Assignment, Dynamic Mode Options, Ordering Options, Grouping Options, Display Options, Advanced, Permissions. The content is located in 2 landmark (banner, main).

In automatic tests only 3 tabs score 95% correctness. 6 tabs score between 75% and 85% correctness, which means that the content is unaccessible.

Failures and recommendations

1. Content outside the landmarks

The toolbar is located outside the landmarks.

Landmarks help assistive technology (AT) users and keyboard users orient themselves to a page and help them navigate easily to various sections of a page. This is not a formal requirement, but the entire content of the site should be inside the landmark regions.

Recommendation: mark the area in which the toolbar is located with the nav tag, because the toolbar is a navigation element.

Note. The toolbar has a correctly assigned attribute role="toolbar". But the toolbar is not a landmark region.

2. The content structure is not marked with headings

Headings are used to create an outline for the page. This page contains a lot of content, but only two headings: the H1 headings with the page title and the H2 headings on the first tab (“Articles Category”). Each tab groups sets of options of a specific type. The tabs names should be headings (H2).

There are usually two groups of options on the Module tab:

• one group is specific for each module (details)
• other group is the same for all modules (Title, Position, Status etc.).

Each of these groups should be marked with the appropriate h3 headings (e.g. “Module data” or “Details” and “Basic options”).

3. Incorrectly named ARIA attribute

All switches (webcomponent: joomla-field-switcher) have a non- existent name aria attribute: “aria-labeledby”. Should be: aria-labelledby (two letters ll)
If the developer uses a non-existent or misspelled ARIA attribute, the attribute will not be able to perform the accessibility function intended by the developer.
Note: Resolve by PR: #23834
This may be the reason that labels are not announced by the screen reader - see below.

4. Labels are not associated with forms

The button for switching options (webcomponent: joomla-field-switcher): When this option is on and the setting is stored in the database, the screen reader announces a label. But when this option is disabled and saved in the database, the screen reader does not announce a label. Instead of labels, the screen reader announces the current state (ex. "Hide").
In the Accessibility tree there is no accessible form name:

On the “Element List” in the NVDA (the list is used for quick navigation between links, headings, form fields, buttons, landmarks) there is no accessible name of the fields and buttons. There are names that are misleading or incomprehensible (correct is marked in blue, incorrect in red color)

Label for the module’s position selection field. The label is not properly associated with the selection list. In the Accessibility tree there is no accessible form name for this form. The focus is invisible.

In addition: The X button is set inside the Position field. The screen reader announces it: Remove item. This message is unclear when "None" is selected.

• Label for Ordering field: The label is not properly associated with the selection list. In the Accessibility tree there is no accessible form name for this form. The focus is invisible. Screen reader does not announce a label. Note: Reported as issue: #23888
• Label for Module Assignment: The label is not properly associated with the selection list. In the Accessibility tree there is no accessible form name for this form. Screen reader does not announce a label. Note: Reported as issue: #23889

5. Incorrect scope in elements with ARIA role

Template position selection list (webcomponent: joomla-field-fancy-select): All tree nodes should be contained in or owned by an element with role tree. Currently tree nodes with the role of treeitem are not correct in element with role group.

See: WAI-ARIA Authoring Practices 1.1 TreeView

Note: Reported as issue: #23887

6. Skip description of the tab contents

When there are many options on the tab, the screen reader announces a description of the tab, for ex.: “Menu Assignment property page”. Suggestion: It would be better to describe: “Menu Assignment property tab”. When there is only one option, the description is omitted.

Each tab shall be described.

7. Hints are not linked to forms

Some forms are accompanied by instructions (hints, tip). For example, a tip to the label "Show on Article Page" on tab Dynamic Mode Options:

“Select to Show or hide Article List from Article Pages. This means that the module will only display itself dynamically on Category Pages.”

A blind user is not notified of them by the screen reader. Add aria-describedby="[id_tip_content]" to form control.
Currently, the aria-describedby attribute is added to the div tag, which includes the form, and not to the input field. As a result, the screen reader does not see the description, because div does not receive a focus.

In addition:

Hints to label “Date format” and “Month and Year Display Format” a hint is placed in the title attribute.

“Please enter in a valid date format. See: http://php.net/date for formatting information.”

The screen reader reads this hint, but this is not a good solution. The title attribute is not recommended and is not needed here. It should be an aria-describedby attribute

8. Links instead of buttons

In the "Menu Assignment" tab there is a collapsible list of menu items. User can collapse or expand the entire list and select or clear all menu items with one click. Unfortunately, a blind user who uses a screen reader hears the content of the links incomprehensible: "All link" and "None link". These links should be replaced by buttons and labelled with accessible labels.

9. Search field not accessible

There is a search box on the Assignment Menu tab. The field does not have an accessible label. In addition, it is not keyboard focusable, because it has been excluded from the tabulation order using the tabindex="-1" attribute.

10. Assignement menu function not accessible to blind users

The user of the screen reader gets access to almost all implemented operating possibilities, but they are not understandable.

1. The "Menu selection" label is not announced by the screen reader.

2. A widget to select / expand menu tree is not accessible because
   a. Does not have an accessible name (headings or label)
   b. “Select” & “Expand” labels are not announced by the screen reader
   c. “All”, “None” options are links instead of buttons.
   d. “All link” & “None link” messages announced by the screen reader are incomprehensible to the blind person.
   
   

3. The names of the menus in which the user is to select are not announced by the screen reader.
   

4. Aliases next to menu item names are unnecessary. They do not provide new information, but they cause information noise, confusion, etc.
   

5. Accessibility errors in the context menu:
   a. Nonconsecutive level heading used. The menu contains an <h5> tag directly following an <h3> (“Sub-items”). In order to maintain a consistent outline of the page for assistive technologies, reduce the gap in the heading level by upgrading this tag to an <h3> or <h2> or see paragraph b. below.
   

b. The names of items in the context menu are unclear. They should rather be: “Select sub-items”, “Deselect sub-items”, “Expand sub-items”, “Collapse subitem”. In this case the heading H5 (Sub-items) is not needed.
c. When you select or deselect from the context menu, all items in the level are always selected, not just the selected item. Blind screen reader user does not see or hear it.
d. Icons next to the names of items in the context menu are unnecessary.

11. Insufficient contrast ratio

The labels of the options set by the switches have too low contrast to the background:

The color combination #868e96/#fefefe has a contrast ratio of 3.29, which is not sufficient. At this size, you will need a ratio of at least 4.5. Consider using the following foreground/background combination: #6d7781/#fefefe / has a ratio of 4.52

Other

12. Unnecessary attribute aria-label instead of attribute alt for graphics

The link to the "Control panel" page has an unnecessary aria-role attribute. The graphics covered by this link (Joomla logo) have an empty attribute alt.
The attribute aria-label should be removed. The non-empty value of the alt attribute should be added to the Joomla logo: “Back to Control Panel”
In addition, a function should be added in the template that recognizes that the Control panel page is active. If the Control panel page is active, the Joomla logo in the banner area should not be included in the link (to the same page).

13. Nonconsecutive level heading used

All page in the Joomla Backend contains an <h5> tag directly following an <h1>. Post installation message module displays messages marked with h5 headings. In order to maintain a consistent outline of the page for assistive technologies, reduce the gap in the heading level by upgrading this tag to an <h2> or add a module title in the h2 tag and mark messages with h3 headings.

Ciaran Walsh asks for tests and comments on the pen for new sidebar.
You can submit your comments immediately to
joomla/40-backend-template#365
or
If you want to discuss them first in the Joomla Accessibility Team, report them to this topic.