search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
Other
2.07k stars 624 forks source link

aria-sort changes not announced when the change is not on the focused element #10890

Open smhigley opened 4 years ago

smhigley commented 4 years ago

Steps to reproduce:

  1. Visit https://w3c.github.io/aria-practices/examples/grid/dataGrids.html
  2. Navigate to the grid in the second example
  3. Navigate to the first column header (the sort state is announced)
  4. Change the sort state

Actual behavior:

Changes to the aria-sort property are not announced

Expected behavior:

Changes to aria-sort are announced

System configuration

NVDA installed

NVDA version: 2019.3.1

Windows version: Windows 10, version 1909

Name and version of other software in use when reproducing the issue:

Adriani90 commented 4 years ago

at least for Firefox cc: @jcsteh is this correctly exposed by Firefox?

Maybe @aleventhal could also comment on Cromium and how is it exposed there.

jcsteh commented 4 years ago

Firefox exposes this correctly and fires the correct events. NVDA even handles these events.

The issue here is that aria-sort is set on the cell, but the element the user actually activates is a button inside the cell. NVDA only reports changes that occur on the focused element, and since the button is the focused element and aria-sort isn't set on the button, no change is reported. Contrast this with aria-sort being set on the focused element activated by the user:

data:text/html,<button aria-sort="ascending" onclick="this.setAttribute('aria-sort', 'descending');">Test</button>

I can understand why it's been done this way. The question is whether it's reasonable to expect NVDA to handle this case, and if so, how NVDA should reasonably handle this. Reporting changes to any element would be bad. Reporting changes to any element in the focus ancestry might do it. Better still, NVDA might want to report changes to any element in the ancestry of the object at the cursor.

TomAuger commented 4 years ago

Question then: does putting the aria-sort attribute on the button address the use case of helping the AT understand that the column that button is present in is sorted in a particular way? Or does the aria-sort attribute NEED to be on the TH in order for it to have any useful meaning?

Put another way, can we simply start putting aria-sort on our inner buttons (inside the TH) as in your example above, or will that not work in actual practice?

TomAuger commented 4 years ago

As an experiment, I removed the inner

jcsteh commented 4 years ago

As an experiment, I removed the inner element altogether, and instead, put the "onclick" handler on the TH element itself

That's what I would have suggested. However, you should also make the th focusable (tabindex) if you haven't already. I don't really see the need for the inner button.

While I was able to change the aria-sort attribute programmatically on the very element that had focus, the change was nonetheless not announced, so I wonder whether the above statement is, in fact, true.

The above statement was specific to Firefox. I tested in Chrome and it is indeed broken there. The problem is that Chrome isn't firing the correct events.

jcsteh commented 4 years ago

Question then: does putting the aria-sort attribute on the button address the use case of helping the AT understand that the column that button is present in is sorted in a particular way? Or does the aria-sort attribute NEED to be on the TH in order for it to have any useful meaning?

Putting aria-sort on a button in actual practice is a violation of the ARIA spec. My apologies for using that simplified example. It needs to be on the th.

jcsteh commented 4 years ago

The Chrome specific issue is covered in #10774.

smhigley commented 4 years ago

@jcsteh a more realistic example of why a grid might control sorting with a button within the cell rather than with the cell itself is when a header cell might have multiple actions that can be taken, e.g. sorting, filtering, selection, etc. Sometimes there are just multiple buttons within the cell, and sometimes there's a single actions menu, where the sort functionality is controlled by a menuitem.

Both of those implementations are allowed by the ARIA spec, but as you mentioned the actual aria-sort value would need to be on the gridcell, even if focus is within it. Do you think supporting that pattern is something you'd consider for NVDA?

jcsteh commented 4 years ago

I understand the use case. I'd agree it probably makes sense to support this, but that's not my decision; I'm not a core developer.

seanbudd commented 1 year ago

Our system test for this is failing, it seems that this issue is a problem again in Chrome.

michaelDCurran commented 1 year ago

It is still working in Firefox. But it looks as though perhaps Chrome is no longer firing a stateChange, or the stateChange is too early, when toggled.

yhy-1 commented 1 year ago

Is there any new update on this? Still experiencing this in Chrome.

Adriani90 commented 2 months ago

@yhy-1, @smhigley, @TomAuger did anyone report this to Chromium bug tracker?