Not in favour of the change in name - otherwise I dont really care

FWIW I really don't like all these random colours, stick to primary colour also for the clear, my 2c

When the 'clear' is for resetting all search and filter I understand why it is highlighted, but I wouldn't make it red. Just different, dark grey. And name it 'Clear all'.

When the 'clear' is only resetting the text search, I wouldn't make it so big, why not x inside the search input field?

I would not use red - there is no danger in clearing filters.

Maybe go with a positive/neutral/negative approach. Primary buttons, e.g the most important ones that should stand out, should use bold colours. For example:

Positive:

• Save: primary background
• New: primary background
• Upload: primary background

Neutral:

• Cancel: red outline and plain background or just plain colours
• Clear: red outline and plain background or just plain colours
• Help: plain colours
• Options: plain colours

Negative:

• Delete: red background
• Ban: red background
• Migrate to WP: red background

Can you make a Screenshot of your suggestions- would be very helpful. ?

Von meinem iPhone gesendet

Am 24.02.2020 um 20:35 schrieb Lodder notifications@github.com:

Maybe go with a positive/neutral/negative approach. Primary buttons, e.g the most important ones that should stand out, should use bold colours. For example:

Positive:

Save: green background
New: green background
Upload: some primary colour for background
Neutral:

Cancel: red outline and plain background or just plain colours
Clear: red outline and plain background or just plain colours
Help: plain colours
Options: plain colours
Negative:

Delete: red background
Ban: red background
Migrate to WP: red background
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I think I found the solution tonight. But therefore I need help @dgrammatiko from the JS guys.
What do you think?

ahhh we already have a concept with search and dropdown but if i remember its not realy accessible ...
an example in an other component

Sorry Angie but that fails in multiple ways

1. There is no clear/reset button
2. It is not possible to see what filters are applied - The indicator you show is meaningless without a label
3. Accessibility

a light idea (maybe bad)
=> fixed search with criteria in bottom list over the content
user can concentrate in content list

I like the idea, a clear button would be good and if we add some more information like "State: Publised" or "Access: Public" it give the user a lot information about the filter state. I wouldn't do the category filter into the search box, I think having this in the same line as the other Filters is more consistend. Should be then "Category: Products, Offers"

"Reset filter" is not as important as "New", therefore is should not be using a dominant colour. It should use the same styling as the current "New" button and the "New" button should be a solid primary background

As I said in a phone call, I don't really like the labels. I think moving the search box and the filter button to the left is fine and especially shortening the filter button to that icon and "Filter". But I don't see the benefit of the labels for the currently active filters. The filter list is always extended when a filter is set, except when a user willingly closes it and even then it extends again when the page is loaded again. That to me just doubles the list of filters. I would support some graphical highlights to show which filters are currently active and which aren't, but not by adding another set of elements in the list. If the goal is to make it clearer that the list has been filtered, then I don't see why people should notice those labels when they ignored the filters up till now.

@Hackwar I assumed those label things were instead of keeping the filter open which couldnt be true if the modal was used as shown to select filters

The story with the filter doesn't really let me go, even if some people think we have no problem with it.
The filter is a technically relatively complex thing. With choises.js we have the possibility to visualize selected elements within a pseudo checkbox.
This is nice, if it is a single separate field with a maximumf 5-8 choices. If the number of selected elements and used select elements increases, it quickly becomes unclear and difficult to use especially from an accessibility point of view.

The buttons appearing in the checkbox have the following information aria-label="Remove item: '432' , in my case this means the user : Angie.

If this is accessible and if the focus is always in the right place - no idea.
For this purpose, user tests would have to be carried out.
Has that perhaps already been done, Brian?

Just a quick look at what I had in mind.
structurallay I would imagine it like this:

<headline> Filter and Sort</headline>
<p class="screenreader"> Filter in use or / Articles filted by:</p>  
 <button >selected category name<span class="screenreader"> unset </span></button>
 <button >selected category name 2<span class="screenreader"> unset </span></button>
 <button >Published <span class="screenreader"> unset</span></button>
 <button >draft<span class="screenreader"> unset</span></button>
 ...
<input type="text" name="searchword"> <input type="submit">
<button>open filter</button><button>clear all filter</button>

=> modal

<div class="filter">
Filter form
</div>

// after submit: Modal close, update content and buttons at the top
=> no need of choises.js
everything is easier

What do you think?
Or have I lost my way?

Angie

@dgrammatiko @chmst
@brianteeman
@infograf768
@awilsonGE
@phproberto
@rdeutz
@Bakual
@Hackwar

Ask the accessibility team

Also see #27741

@angieradtke
Looks like you had modified in your big PR the svg background in variables but forgot to do it for RTL

you did
$custom-select-indicator-active: url(../../../images/select-bg.svg);

but forgot to also change
$custom-select-indicator-active-rtl: url(../../../images/select-bg-active-rtl.svg);
to
$custom-select-indicator-active-rtl: url(../../../images/select-bg-rtl.svg);

which therefore gives

instead of

Shall we create a single PR for that or wait your further work on this?

Really struggling to understand why there are different SVG's for LTR and RTL. The only thing that needs changing is the background position

The reason is that the SVG is full width with the arrow at the edge. Don't ask me why it is done that way though

Ah yes I noticed that when testing another PR. I did state that the SVG didn't seem right. I think people like a maintanence challenge these days

Regarding A11y, we have been discussing this thread on the JAT and we want to share our conclussions on this matter. First of all, please keep in mind that as this is a concept, we cannot provide lots of specifics and we are testing against what it's currently implemented in the latest nightly build:

Issues of current implementation

• Multiple choice filters are mixed with single choice filters and not correctly announced to the user
• On any filter selection, the page directly reloads without notice or further user interaction
• There are too many elements

Recommendations

• Reorganize selection lists into two groups:
• Single choice lists
• Multiple choice lists
• Announce to the user that he has a multiple choice list
• Integrate the full ordering selection and list limit into the filter panel

Further requirements:

• The filter panel must be announced and described by screenreaders.
• Special challenge are multiple selection list (i.e. categories).

In general Angie’s proposal (#28056 (comment)) is not bad, but these recommendations need to be addressed in the final implementation.

Thank you very much for your patience on this.

Best!!

--
Joomla A11y Team

#27741 sat there without any interest so it was closed. That resolves the filter select notification. As for mixing single and multi select - there is nothing wrong with that

Hi @brianteeman ,
thanks for the reference. I have to admit when I got informed of that issue the whole COVID problem exploded at my face and I failed on keeping track on it. We can check it again if you kindly reopen the pr.

Anyway, as far as I can see the referenced PR only affects table captions and it does not explore the filtering issue we are discussing here.

Stay safe!!

You will have to rebuilt as I have deleted the branch

No it absolutely is about table filters and ensuring that the active filter is communicated

@angieradtke is this reply enough for you to make a new proposal?

Thanks!!

Hello, everyone,
the filters have been as they are for a long time. Nothing is more difficult to change than habits. That is why I think that possible planned changes should first be discussed in the PLT, because it takes the willingness to change and the need to recognize this.

After that it should be checked if there is somebody who is very familiar with the existing implementation and knows possible side effects. Then it should be discussed how to implement the new filters. My ideas can be found above.

Here I consider the Accessibility Team to be absolutely necessary to test intermediate results promptly. To make these tools really accessible it needs the will, experience and tests. That's not something you just do.

But I think without this change the accessibility of the backend template is limite.

Bye and stay healthy
Angie

I agree. I think that all users will appreciate this concept. It is clear, easy to use and I see it in online shops, So if we could start this as a draft PR, I will do what I can for testing.

I have no idea which is the proposal you are suggesting

Brian: Please scroll to the beginning of this thread .
Stay healthy

So is it the first post you are proposing or any of the later ones which are very different

if WCAG AA is the goal then this issue is a release blocker .-(
@wilsonge

Instead of a blanket statement please explain where it is failing accessibility specifically which rules

2.1, 2.4. 3.2 Please Brain, read the thread from top to down. I made examples already. Now is the time for a decision. Change or not.
If not, then that's the way it is, maybe other things are more important. But that leads to that I don't have to care about that issue anymore . I do not want a power struggle here, but only point out problems.

Yes but I do not know which of the many examples you have made are the ones you are proposing.

oh , communication- difficult as usual .-)

The search tools cause problems in many ways and are difficult to use for people with various disabilities.

Besides the verbal communication of the content the user should know which element has the keyboard focus. This are are the biggest problems , I think

The complexity of the code is also reflected in the complexity of the problems. Reducing complexity can leads to a better accessibility and easier maintance, I think.

Example for wrong text -> category-filter id is used instead of title in aria attribute

<button type="button" class="choices__button_joomla" aria-label="Remove item: '8'" data-button="">Remove item</button>

So nobody knows its category-ids .-)

Greetings Angie

Example for wrong text -> category-filter id is used instead of title in aria attribute

That's actually a bug in choices. I've done an initial PR because that language string is actually hardcoded: jshjohnson/Choices#863 then will follow up with something to use the option value there rather than the actual code value

Also please test #28997 as it provides the filtered state that you need

@angieradtke Is this still a valid issue or we can close it?

Dear Tuan, dear team ,

this is one of the more complex problems we neeed to solve. I have to look at it again, maybe something has changed and I missed it. If we are going to do this, it has to be done in cooperation with JXT and the accessibility team. I'll make a new inventory.

I think we should split this issue into pieces.
First thing that sould be solved:
Example for wrong text -> category-filter id is used instead of title in aria attribute

aria-label always wins over default accessiblename

<div class="choices__item choices__item--selectable" data-item="" data-id="1" data-value="8" data-custom-properties="[object Object]" aria-selected="true" data-deletable="">**Itemname** <button type="button" class="choices__button_joomla" aria-label="Remove item: '8'" data-button="">Remove item</button></div>

of all the problems that is perhaps one of the least important

But if anyone wants to look at this then its a combination of joomla-field-fancy-select and choicesjs

What should we do with this issue? Is this still relevant? I've grown accustomed to the filters we have right now... ? If there are still problems, can we split them into separate issues and close this one?

Maybe we can close this as there was no discussion since 6 months? @Hackwar

I’ll close for now. Always happy for more concrete suggestions or to reopen but in the absence of progress here for 4 years going to close this down for now