I've been dabbling with trying to make it keyboard accessible the last week (note just trying to make the existing markup give or take work - not trying to convert it to a table unless that's a hard requirement). I can push up some incomplete work on it if it helps too.

By the way the one thing I can't work out. If i open the 'dropdown' that has the action buttons (i.e. edit etc), it resets the keyboard focus back to the html tag in the dom. is that expected when the dom is mutated or some weird part of vue.js or something else?

Tabular data should be presented as a table.

When you navigate through a table with your eyes you are able to understand what the data represents because you can see that it is in a column called size.

When you navigate through a table with a screen reader you can hear what the data represents because you can hear that it is in a column called size.

That's what all the pull requests using scope did)

Go with a simple unordered list when you only list single-dimensioned or unstructured entities.
Go with a description list when you have structured name-value pairs for one entity.
Go with a table when you list several structured entities that could be compared.

Finally
Do you need some kind of cross-referencing and/or sortable on different properties of the individual items? If so then use tables

Note that you can not sort the media manager list view at all by any of the pseudo columns

And I will repeat what I have said since the first public release of this media manager. Requiring a double click to select an item is just plain wrong.

By the way the one thing I can't work out. If i open the 'dropdown' that has the action buttons (i.e. edit etc), it resets the keyboard focus back to the html tag in the dom. is that expected when the dom is mutated or some weird part of vue.js or something else?

without seeing the code I cant tell

I'll push it into a local branch tomorrow (as i said it's still a long way from finished - so no point in making it a proper PR yet) so I can demo some of it.

the main thing about using lists would be that this would be different to every other view in joomla and that you can not do any type of sorting. Both of these issues make it less accessible by design even if the code is tweaked to satisfy automated tests

I am currently testing a new media manager. I confirm Brian's observations. Please take a few days (5-6) for a detailed evaluation and description.

https://github.com/wilsonge/joomla-cms/tree/media-manager-ally

Here's my WIP branch. I'm absolutely certain it won't be close to fully keyboard accessible yet. But should be a step in the right direction.

So what is in here is that tabbing takes you through the images and now will blur out the images to show the action areas. For the dropdown menu you can use enter to open it and escape to close it (no clue if they are the right buttons but that's easy enough to change). But when the menu appears/disappears the focussable area resets. Also hitting enter to open the menu selects the item - didn't have time to look into that yet. Also I've largely limited myself to working on the images in the list view - and then expanding that concept out is easy.

As I said it's still a long way from finished

Before I test did you make any changes to the list views as they are the biggest problems

No. I've been working on tabbing through the browse view (not sure if there's a name in the interface and browse is what's in the code) and using keyboards to open the menus:

Ok. Now I know which parts to test :)

Other than the cropping I'm not sure this is an improvement

When you tabbed through the elements before you still actually focussed on the dropdown/select box - they just weren't visable to the user. Now they are and the dropdown can be opened with the keyboard. That's the major change. I don't think I've changed the edit view?

Pushed a couple of fixes up - I think this fixes a most the bugs aside from when you open the menu with enter it also selects the item. I've spent the last hour trying to figure that one out and totally failed. So I'll leave it for another PR. Does the browse stuff become vaguely keyboard accessible with that branch?

@wilsonge you haven't enabled creating issues on your fork so reporting here purely about keyboard navigation in the thumbnail view

1. No way to access the category tree
2. tabbing to a folder has no visual indicator and the two hidden buttons never get highlighted as they do when you mouse over (see video at bottom)
3. If you guess that you are the first folder button then it can be selected with the enter button but not the space button
4. However you cannot enter the folder at all which together with point 1 means that a keyboard user can never get beyond the root
5. If you guess that you are on the second folder button then you can never select it
6. tabbing to an image correctly highlights the image and the two buttons which can both be selected with the enter key but NOT the space
7. When additionally using a screen reader at no point is the name of the image or folder ever announced - everything is an item. This is the output from the screenreader.

Toggle item info
link
clickable
Toggle select item
link
Open item actions
link
clickable
Toggle select item
link
Open item actions
link
clickable
Toggle select item
link
Open item actions
link
clickable
Toggle select item
link
Open item actions
link
clickable
Toggle select item
link
Open item actions
link

Below is a screen recording with additional highlighting to show where the tab takes you so you can see the lack of visual notifications

@brianteeman : How do you register the order of the tabulation? What application do you use?

Sorry I don't understand the question

@brianteeman @zwiastunsw is asking what application you used to register this red line on image in #23932 (comment)

Chrome lens

@brianteeman

1. No way to access the category tree

I've made it accessible so you can navigate back up the tree (was as simple as adding # as the href attribute to the links)

2. tabbing to a folder has no visual indicator and the two hidden buttons never get highlighted as they do when you mouse over (see video at bottom)

Fixed - as a demo I'd only done this for image type files - now rolled out to directory, file (e.g. pdf's) and video (mp4) formats too

3. If you guess that you are the first folder button then it can be selected with the enter button but not the space button

Fixed this for opening the dropdowns. Didn't for opening all the relevant modals - is space the same as enter for a11y or? I mean it's easily fixable - just trying to figure out what the spec is

4. However you cannot enter the folder at all which together with point 1 means that a keyboard user can never get beyond the root

Haven't fixed this one yet - unsure what the best approach is tbh - suggestions appreciated

5. If you guess that you are on the second folder button then you can never select it

Fixed (related to number 2)

6. tabbing to an image correctly highlights the image and the two buttons which can both be selected with the enter key but NOT the space

Related to 3 as to whether space is relevant - easy fix if required for everything

7. When additionally using a screen reader at no point is the name of the image or folder ever announced - everything is an item. This is the output from the screenreader.

OK is this just adding title attributes to the links or?

@wilsonge

3.https://webaim.org/techniques/keyboard/

7.I would try changing
aria-label="Toggle select item"
to
aria-label="Select <>"

That really should be a checkbox not an a href though as it is not a link

will test more in the morning

3/6. - OK So reading your link I'm slightly more confused. Links are just enter (which is what we have). If we make it a button by adding a role=button (which these don't have right now - although arguably should) then it should trigger on space OR enter - so why do we need both?

7. You're totally right. If it's as simple as a string change if you propose a string for those two I can get that implemented straight away :) Looks like there's already a rudimentary sprintf implementation done https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_media/resources/scripts/plugins/translate.js so I can just run it straight through all being good

That really should be a checkbox not an a href though as it is not a link

It should - but then we somehow need to wrap everything in a form. Which is going to get dodgy from other angles I guess :/

but they are not links are they.

and role=button on an "a" will only make it report as a button. it still wont work as a button for keyboard users

ahh sorry I misread - i interpreted it as one or the other should work. Not using one or the other will work

OK So the menu trigger is now done correctly. Should the links opening modals report as buttons two (and act accordingly)

if it looks like a button then it should act like a button :)

buttons are to perform actions
links should only be used to open a new page or jumpt to a section in the same page
https://a11y-101.com/design/button-vs-link

Github mangled by suggested change for the aria-label

it should be Select filename and Select foldername

Remind me again of the advantages of this new media manager because at this point I really dont see it or the advantage of writing it in a language that our contributor base are not familiar with. It doesnt even offer the one thing that was specified for a new media manager - the ability to see if an image is being used etc.

Remind me again of the advantages of this new media manager

• Significantly nicer interface (no page reloads every time you go into submenus etc)
• Image editing (we can go more complex than what is there - as it basically just goes down into implementation and browser deps)

Like I understand that the contributor base is largely PHP - but most our competitor PHP CMS is basically having to enter the JS world for some frontend stuff. Honestly it's taken me the best part of two evenings after work to understand what's going on. It's not crazy simple of course. But I would say this vue implementation is simpler than any react implementation would be.

just expressing my frustration that the delivered code is not up to standard and abandoned by those who wrote it and only developers who know vue can contribute to fix the mess.

I know it's fraustrating. But I promise if you spend a little bit of time on the templates it's not as bad as you think. It's honestly taken me a handful of evenings after work from never having touched vue.js before to get up to speed (admittedly I'd dabbled in react and angular before now - but not sure it was significantly helpful)

1. The Delete button in the Toolbar removes selected files and folders without warning.
2. Folders are deleted with the entire content without warning. In Joomla 3.x it was not possible to delete a folder with content.
3. An anchor is used to select a folder / image. This is neither a link nor a button. Native element of HTML, which is used to select he position is the checkbox. No link, and no button.This should be a checkbox.
4. There is no "Select all" option.
5. The keyboard user still cannot open the contents of the folder.
   • In Joomla 3, the contents of the folder were opened with one click on the body of the folder card. In my opinion it is necessary to restore this functionality or add a button (?), which will open the folder .
   • In Joomla 3 the folder name was a link to open the contents of the folder. Here it is plain text. I suggest restoring the solution that was in Joomla 3.
6. The ability to use the Drag & Drop function is not signaled to users at all. (Is this a hidden function? Try dragging and dropping the image. The "Drag & Drop" interface will appear. This function does not work.

@zwiastunsw The delete warnings are in this pr #23756

The select all is present - but hidden a little - it is the link that looks like a checkbox that is in this image

The select all is present - but hidden a little
Really. :)

I think nearly all of this is now captured in joomla/accessibility#58 ?

@wilsonge : I will work on this report and complement it. I will also mark in it the problems that have been solved. Thank you for your work on the accessibility of Media Manager.

If the skipto code is resurrected then it would solve many of the issues about getting to the media manager that you reported. I just am not prepared to do it and for the JAT to ignore it again

@brianteeman: If you have time to finish it, you will simply resurrect it. Patience is a virtue of gods (and leaders).

I am many things but I am not god ;)

Closing this as I've merged most the things and we have the issue in the accessibility tracker to deal with the remaining issues. We can open issues here for specific items