Visual label not provided for filter input fields

[saychakraborty89]

Description

This issue is being reported as per the discussion in support issue-C-00235203. The issue is that there are no accompanying labels with the inputs appearing next to filter buttons.

ignite-ui version: 23.2

• browser: any

Steps to reproduce

1. Go to the sample igGrid demo.
2. Navigate the datagrid through keyboard to reach the text input box next to a filter button having "Contains" as a placeholder text.
3. Notice that the edit-field "Contain" doesn't have a visible label that describes its purpose. For example, if you are entering in a column of addresses, a visual label like - "Please enter a country, city or zip code". would be helpful.

Violated Accessibility Guideline

This violates 3.3.2 - Labels or Instructions of WCAG 2.0 level A.

Result

Visual label is not provided for the edit-field "Contain".

Expected result

There should be a label descriptive enough to describe the purpose of the input fields next to the filter buttons.

Suggestions

As the datagrids would not know what a column means to the consumer, igGrid may provide an API to the consumer to provide a meaningful label to the filtering input, should the consumer find it necessary.

Attachments

Attach a sample if available, and screenshots, if applicable.

[ChronosSF]

@saychakraborty89 , I don't completely agree with the suggestion that labels should be exposed. The section mostly covers forms which the filtering editors aren't part of. Or in a broader sense the ability to clearly distinguish the purpose of the editor using visual ques. Labels will look quite out of place in the grid cells taking too much space and only providing redundant information as the editor's place in the columns clearly marks them as something affecting the column itself while the placeholder suggests filtering and the currently selected condition.

In my opinion, if users want to add some context to the filtering, e.g. when they have custom filtering implemented that they want to guide end-users with, we can expose the ability to set titles to the editors. The title popup just fits the design and space constraints in the grid a lot better than labels.

How does this suggestion sound?

[saychakraborty89]

The trouble is not only with the custom filtering. The accessibility issue remains with normal filtering as well. So, even if you do this, the issue would remain open.

[ChronosSF]

@saychakraborty89 , we are already improving the aria-label of the editors as part of bug #2242 . If you insist on having a visual label, because of how space-sensitive this area is in the vast majority of cases, I can propose a workaround you can apply just for your apps. Basically you can inject labels and make them position properly with a bit of CSS. I am demonstrating one approach for this in the sample attached but there can be many ways for this to be done depending on how you'd like these to look.

sampletest.zip

[saychakraborty89]

We would not like to tamper with ig datagrid html, mostly because it is less likely to be accepted by our stakeholders. It would be great if you could provide an API which we could leverage. That way, people not opting for labels would find no impact.

[ChronosSF]

@saychakraborty89 , I understand. Could you please check the sample anyway and let me know if it's more or less what you'd expect as an end result?

I really don't think the visual label would be used because the purpose of the editors can be inferred by their position and additional UI and it could also be read as an aria-label by nvda. Adding one just doesn't fit 95% of the grids where the width of columns is made as small as possible and if the label takes space from the editor it will hardly fit what end-users would like to write in it.

If you agree on the general design we can add the label through an editor option but since it will be a new property, it will have to be handled as part of a feature cycle so we won't be able to deliver it that quickly. You should expect it around November.

[ChronosSF]

@saychakraborty89 , after discussing this internally a colleague gave a suggestion to expose the editor placeholder text option as a potential replacement for a full label. Currently it just displays the condition but it's not difficult to expose for modification. Would that work for you as an alternative or we would prefer a full separate label to the left or top of the current editor?

[saychakraborty89]

The current usage of placeholder text illustrating the selected condition seems fair and useful. I would not recommend changing that for this issue.
I think going ahead with a new feature, as discussed earlier on this thread, would be the most acceptable approach.
Hope to get it on the other side of November this year.