Re: Sortable tables how to design/ describe icons for not sorted/ ascending/ descending

Issue 1: About arrow up/down:
An arrow pointing upwards to signify ascending is correct as you also
conclude "where the lowest is on the top (which is logically right..."
And an arrow pointing down  correctly signifies descending order.
Regard the arrow as a triangle  with the tip representing the lowest
value and the base the highest.
So there is no problem there.
The arrow is used to visually indicate the sort order- this is
important for a visual interface and commonly used icons do not need
text within the icon simply because they are well understood and
common.
So one has a printer icon to indicate printer friendly page with no text within.
Yet,   sometimes there is a printer icon with the word "Print" within too.

Likewise if one believes the up / down arrow icons  might be unclear
to some users, surely one can  include text like "Asc" / "Desc" within
the image. That is a matter of inclusive design and good practice.
And of course the alt  for the icon or other property for the  button
should reflect the correct sort order SC 1.1.1.
Issue 2: Button state  from not pressed to ascending to descending:
This has been a long standing practice : A data table is presented
with data rows sorted or not sorted as the default view based on
author's choice.
If sort feature is available, activating the button for a particular
column makes that column the currently selected sort-column: generally
ascending by default. The second activation reverses the direction. It
is simply a toggle from asc to desc and back. If the button for
another column is activated, the sort button for all other columns
goes to not pressed state or inactive sort.
I do not see a problem here.
Depending on the design and  use, simply refreshing the page can
present the table in its original default view. Or there can be a
button to make that happen.

Also note: The intent of  Success Criterion for label in name  is to
ensure that the words which visually label a component are also the
words in the accessible name. So this SC is inapplicable here.

Thanks,
Sailesh

On 5/4/19, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> On 04/05/2019 16:03, Marc Haunschild wrote:
>> I still think about the problem and in my opinion it’s a problem
>> violating a wcag success criterion
>>
>> We have success criterion 2.5.3 in wcag 2.1 (Label in name
>> <https://www.w3.org/WAI/WCAG21/Understanding/label-in-name>).
>>
>> I think: The buttons for sorting a table are interface components in the
>> meaning of this success criterion. So it seems to me even the  is on my
>> side (not that I care 😉 - But i do care about accessibility issues,
>> even when they are not covered by wcag)...
>
> Normatively, 2.5.3 is only concerned with readable text - punctuation,
> or any other characters/graphics/symbols, are excluded from it. Of
> course, accessibility goes beyond just WCAG, but you can't bend the
> interpretation of the SC to a fail when it normatively isn't :)
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>


-- 
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Mobile: 571-344-1765

Received on Wednesday, 8 May 2019 21:14:07 UTC