RE: Sortable Table Focus Order

It may not be ideal for the end user, but it doesn’t violate 2.4.3. The page can reload for any link, sorting a table or otherwise. On reload, focus is generally at the top of the page.

There are a lot of situations where it’s easy to argue that a page shouldn’t reload for a given change to some of the content. But WCAG will probably never mandate those cases for a variety of reasons. I can’t see anybody requiring the use of JavaScript and ARIA when standard, compliant HTML will do the job.

It can also be argued that if WCAG did try to do this, it would add entirely too many subjective arguments that couldn’t be resolved. Is it a failure to reload the page if the page is meant to be used as an iframe, and only contains the table in question? In that case the user isn’t actually being inconvenienced, so the rule would need to consider such a thing. Is it a failure if you have a huge form that posts filters, sorting criteria, and other data just to change the search results section? How much of the page needs to change in order to call something “too small” for a full reload?

From: Adam Cooper <cooperad@bigpond.com>
Sent: Wednesday, April 3, 2024 17:00
To: 'Steve Green' <steve.green@testpartners.co.uk>; 'P A F' <pafalways@gmail.com>
Cc: 'Juliette McShane Alexandria' <mcshanejuliette@gmail.com>; w3c-wai-ig@w3.org
Subject: RE: Sortable Table Focus Order

Yes, there is a difference, but only because industry has reduced the utility of WCAG to an auditing tool whose affect usually comes much too late in a product lifecycle.

The ‘guidelines’ aspect of WCAG is now long neglected with interests captured almost entirely by ‘compliance audits’

It does fail 2.4.3 and it is an accessibility barrier in my view.

I have argued for such a change many, many times before successfully with developers who can see that such behaviour is an accessibility barrier for certain users just like the other examples I cited below.

That cost and inconvenience are posed as immutable obstacles to meeting the needs of people with disability demonstrates how far we still have to go.

And, before you cry ‘it’s the reality’ or other such pragma, it doesn’t have to be the way that it is.

About this, I guess we will have to agree to disagree.



From: Steve Green <steve.green@testpartners.co.uk>
Sent: Thursday, April 4, 2024 9:48 AM
To: Adam Cooper <cooperad@bigpond.com>; 'P A F' <pafalways@gmail.com>
Cc: 'Juliette McShane Alexandria' <mcshanejuliette@gmail.com>; w3c-wai-ig@w3.org
Subject: RE: Sortable Table Focus Order

There’s a difference between what you would recommend before anything has been built, compared with something that already exists. Before this page was built, you would argue very strongly to use a button to re-order the table contents without a page reload.

But given that it exists and there’s a cost to changing it, you need to make a stronger case for doing so. It doesn’t violate any WCAG success criteria and there’s no evidence it’s any sort of accessibility barrier. It’s just an odd way to implement the feature.

The sort control is a link, so no one should be surprised it loads a new page. That’s what the vast majority of links do.

Steve


From: Adam Cooper <cooperad@bigpond.com<mailto:cooperad@bigpond.com>>
Sent: Wednesday, April 3, 2024 11:20 PM
To: Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>>; 'P A F' <pafalways@gmail.com<mailto:pafalways@gmail.com>>
Cc: 'Juliette McShane Alexandria' <mcshanejuliette@gmail.com<mailto:mcshanejuliette@gmail.com>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: RE: Sortable Table Focus Order

That’s why the sort control should programmatically be  a button because it performs an action rather than navigates.

not all hyperlinks cause or should cause a reload (e.g., skip to or back to top).

the reload behaviour when activating a sort control is exactly what is NOT expected regardless of how it is implemented.

It is the operational efficiency of the view that is not preserved when focus becomes indeterminate/returned to the document … just like not managing focus when a dialog is displayed or when items are removed from a list etc.




From: Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>>
Sent: Wednesday, April 3, 2024 7:10 PM
To: P A F <pafalways@gmail.com<mailto:pafalways@gmail.com>>
Cc: Juliette McShane Alexandria <mcshanejuliette@gmail.com<mailto:mcshanejuliette@gmail.com>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: RE: Sortable Table Focus Order

SC 2.4.3 doesn’t apply if the page reloads. The behaviour is exactly what you would expect after operating a link. It’s not as good as updating the table without reloading the page, but it’s an inconvenience rather than a blocker and it sounds pretty insignificant if a user is only likely to change the sort order once or twice. Most websites have got much worse accessibility issues than this.

Steve


From: P A F <pafalways@gmail.com<mailto:pafalways@gmail.com>>
Sent: Wednesday, April 3, 2024 9:03 AM
To: Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>>
Cc: Juliette McShane Alexandria <mcshanejuliette@gmail.com<mailto:mcshanejuliette@gmail.com>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Re: Sortable Table Focus Order

The interactive element is a link. So, I did not speak of 3.2.2. The closest SC I thought applied was 2.4.3. I was looking at the operability part of that SC. Could it be OK in terms of WCAG but not great for the user?

P A F

On Wed, Apr 3, 2024 at 8:22 AM Steve Green <steve.green@testpartners.co.uk<mailto:steve.green@testpartners.co.uk>> wrote:
SC 3.2.2, On Input only applies when changing the setting of a user interface component. It does not apply when buttons or links are operated.

The initial post does not say what the “interactive sort element” is. If it’s a button in each column header, SC 3.3.2 will not apply. If it’s a combobox or set of radio buttons, SC 3.3.2 would apply if the page reload is caused by a change in the setting. It would not apply if the new setting is applied by operating a button.

Steve Green
Managing Director
Test Partners Ltd


From: Juliette McShane Alexandria <mcshanejuliette@gmail.com<mailto:mcshanejuliette@gmail.com>>
Sent: Tuesday, April 2, 2024 5:29 PM
To: P A F <pafalways@gmail.com<mailto:pafalways@gmail.com>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Re: Sortable Table Focus Order

Hi there,

That sounds like an issue under 3.2.2, On Input<https://urldefense.com/v3/__https:/www.w3.org/WAI/WCAG22/Understanding/on-input.html__;!!C5qS4YX3!GMMXLOUR9hh7gravXrFx9Vpe4hcmZ3FMVYbaR9TZAGJPpB4Cnvtol_Qpcs1Rv3k-4cyBSkPorKjcUkTYuMCz$>. What you are describing is considered a 'change of context<https://urldefense.com/v3/__https:/www.w3.org/WAI/WCAG22/Understanding/on-input.html*dfn-changes-of-context__;Iw!!C5qS4YX3!GMMXLOUR9hh7gravXrFx9Vpe4hcmZ3FMVYbaR9TZAGJPpB4Cnvtol_Qpcs1Rv3k-4cyBSkPorKjcUuEIzHwn$>'. The solutions here are to adjust the behavior of the component so it does not reload the page or to provide a warning before users encounter the controls that interacting with them will refresh the page.

Hope this helps!

Best,
Juliette

On 4/2/2024 9:26:10 AM, P A F <pafalways@gmail.com<mailto:pafalways@gmail.com>> wrote:
Hello,

I'm using a sortable table. If I activate an interactive sort element, the webpage refreshes and my focus is at the beginning of the webpage. I'll need to renavigate the content I've seen. Does it go against 2.4.3 Focus Order? Is meaning and operability preserved?

P A F