Add a enabled and disabled section to the tour list page

Thanks for the MR! A few quick observations:

I would rename the titles from "Enabled tours" to "Enabled" and "Disabled tours" to "Disabled". That way it would be inline with the views list page for example.

When you disable a tour the default option on the drop button is Edit, while on the views list page for example Enableis the default option. The latter is probably the preferable option for the tours list page as well imho for consistency reasons.

And i like that you have added a plain info text in case no tour is disabled, on the tours list page you have an empty table just showing the table header. something to consider for the views list page as well the other way around?!

Addressed the first two parts.

About the third I don't think having an empty table makes much sense and seems like a bug on views_ui. The empty text doesn't actually appear either.

Surprised it's not an accessibility issue to be empty.

About the third I don't think having an empty table makes much sense and seems like a bug on views_ui. The empty text doesn't actually appear either.

that is what i implied, that your approach here is the cleaner and more correct one and it might be reasonable to open an issue for the views list page perhaps?

aside that i'Ve tested your applied changes, thanks for the fast fix .i'Ve compared the views list page and the tours list page further. one detail the tours list page is missing i'Ve noticed is the focus management. if you disable a tour the focus is lost while if you disable a view the focus is on the then on the disabled view and its drop button with the default option enable.

quickly created a recording on the views list page. as you can hear and see the actions disable and enable are missing the context. what are you enabling and what are you disabling, that is not audible (same for tours but there the focus is dropped as well therefore i used views to illustrate the problem).

Views is using ajax while tours is not.

So question is do we need ajax for accessibility.

the only points i've raised in #9 ✨ Add a enabled and disabled section to the tour list page Needs review where about focus and the missing context in button labels when you are enabling and disabling a tour. that doesnt have necessarily anything to do with ajax and views or am i missing something?

the only detail mentioned in #9 ✨ Add a enabled and disabled section to the tour list page Needs review in the context of views was the point of empty tables. but my suggestion here was to create an issue for views instead. the tour module is doing that aspect in a much better way imho.

Sorry just seeing this. So in views the reason the focus stays is because it’s not reloading but doing an Ajax call for disabling. In tours we reload the page

uhhh now i understand. thought the ajax was only about the ability to filter a list. hmmm well the problem simply is, in the current state if you enable or disable a tour the focus is entirely lost and you have to restart every time from the top of the page - dragged out of your current context. so it is sort of problematic. and then there is the other problem mentioned in #13 that the 22 buttons and links are missing context. at the moment you have 22 times list additional actions and 22 times edit in the voiceover rotor. it would have to be edit [tour name] and list additional actions [tour name]. tricky :/

Ah that should be an easy fix for the labels. Did a fix similar for admin content view using sr only text

For switching up to Ajax that may be a follow up

Will knock both those out tomorrow

Added aria-labels like we do for admin/content view.

Opened 📌 Change disable/enable links to use ajax Active for changing to ajax. Believe everything for the scope of this ticket is addressed.

thanks for opening the followup already! and in regards of the aria-label, i've quickly tested. yes it is inline with admin/content now. but nevertheless i might argue the list additional actions buttons are still redundant without any context. and if someone is navigating by the voiceover rotor you have links and buttons in separate sections, therefore the context is missing if you have the link with context (edit button) proceeded by the list additional actions button. based on the order one could assess the list additional actions button has the same context as the link right before in the dom order. but that requires a certain cognitive load. but in the rotor you see the buttons alone in their dedicated section and so you have 22 redundant buttons still. therefor it might be still reasonable adding the context to the list additional actions button as well. screenreader users can drop of at any time from the announcement when they heard enough. and by frontloading the action the button is about, the important info is known and the person can keep on listening to the announcement if necessary.

Seeing as this is almost following what core is doing is this out of scope now.

Actually 100% of out of scope, this is a core problem. Nothing we are adding.

Automatically closed - issue fixed for 2 weeks with no activity.