search

accessibilitysupported / a11ysupport.io

Accessibility Support data for various HTML, ARIA, CSS, and SVG features
https://a11ysupport.io/
Other
282 stars 33 forks source link

aria/aria-sort_attribute Want to contribute #133

Closed aardrian closed 4 years ago

aardrian commented 4 years ago

I don't know where to start.

I would like to contribute the information I found in my testing (captured at https://adrianroselli.com/2020/09/sortable-table-column-mad-libs.html), and I understand the material I provide must be in JSON.

I have no build tools and I use GitHub desktop. For the limited time I have available, I am more interested in contributing content than learning the process.

I understand I need to make a minimal test and go from there. Is it possible to create a stub for each so I can submit PRs to that?

mfairchild365 commented 4 years ago

That’s totally understandable. I’d be happy to set up some stubs.

Just so that I understand correctly, is this the actual content that you tested? https://cdpn.io/aardrian/debug/NJQNQV

I won’t have any time to do this today, but hopefully later this week.

aardrian commented 4 years ago

Yes, that is the content I tested. But I would build a simpler test case so that just the aria-sort is used.

mfairchild365 commented 4 years ago

I like the idea of a simpler test case. If you throw together a pen, I’ll port it over and set up the test JSON. The content of the test JSON depends on the content that will be tested, as it describes what and how the test should be executed.

aardrian commented 4 years ago

Simple enough or would even simpler be better? https://codepen.io/aardrian/pen/XWdZWzJ

I can dump all the styles, lose the SVGs, and cut back the rows and columns.

mfairchild365 commented 4 years ago

I generally strive to use the least amount of fluff when writing the html; just enough for it to be functional and somewhat match a real-world example. It’s a bit of a balance. The reason I do this is to reduce the opportunity of interference.

If you think you can cut some fluff: go for it 🙂

aardrian commented 4 years ago

Simplified. Looked at a couple other table test pages and figured I could leave the borders in there. I also replaced the SVGs with up/down arrow characters because I still want a sighted user to get visual confirmation the sort happened for testing.

mfairchild365 commented 4 years ago

Thanks! I added assertions (expectations) and a test with https://github.com/accessibilitysupported/a11ysupport.io/commit/e26907601856012df0ae167707dcc82680e1a749

You can view the test at: https://a11ysupport.io/tests/tech__aria__aria-sort and HTML file at https://a11ysupport.io/tests/html/aria/aria-sort.html

Huge note: I modified the code pen that you provided with the following changes:

I'm happy to hear arguments to more closely match what you provided.

Also a few questions after reading your blog post: I don't typically test with iPadOS. Do you think it would be worthwhile to test that combo here? I also don't typically test with Talkback and Firefox, although it is listed as an 'extended' combination in this project.

The file that you will want to make a PR against to submit data is https://github.com/accessibilitysupported/a11ysupport.io/blob/master/data/tests/tech/aria/aria-sort.json

Let me know if you need help following that structure. There are also some properties such as notes that are not included by default, but can be used to add important info. See this aria-expanded test as an example.

mfairchild365 commented 4 years ago

@aardrian just want to make sure you saw this. Let me know if you need any help or if you have any questions. If you are too busy to contribute results in the next few weeks, I’m happy to do it myself. 🙂

aardrian commented 4 years ago

I saw it. And it is in my queue. I am just behind on everything in my queue this week. But do keep pestering in case I lose it (though I have this tab open as a reminder).

aardrian commented 4 years ago

PR https://github.com/accessibilitysupported/a11ysupport.io/pull/135

aardrian commented 4 years ago

Also a few questions after reading your blog post: I don't typically test with iPadOS. Do you think it would be worthwhile to test that combo here?

No. At least not until I see some divergence in support.

I also don't typically test with Talkback and Firefox, although it is listed as an 'extended' combination in this project.

I have been paying attention to it more given it performed better with role="doc-subtitle" (per my post on same)

mfairchild365 commented 4 years ago

Thanks! That's a good data point re Talkback and Firefox. And thank you so much for the PR!

I merged your PR and ended up making some modifications:

  1. Everything for the none value was marked as fail. I changed this to pass because the absence of any sort information in the announcement should convey that it is not sorted. Do you agree?
  2. ascending and descending were marked as partial for MacOS+Safari. I assume this is because it was announced as sort up and sort down. I think the sort direction is minimally conveyed by those announcements, so I changed it to pass. Do you agree?
aardrian commented 4 years ago
  1. Everything for the none value was marked as fail. I changed this to pass because the absence of any sort information in the announcement should convey that it is not sorted. Do you agree?

No. The presence of the attribute should indicate to users that the column can be sorted. Without any programmatic indication the burden falls on the developer and history suggests that does not always go well.

  1. ascending and descending were marked as partial for MacOS+Safari. I assume this is because it was announced as sort up and sort down. I think the sort direction is minimally conveyed by those announcements, so I changed it to pass. Do you agree?

No. I marked it partial because it did not announce the sort state when I tabbed to the control.

mfairchild365 commented 4 years ago

Great points.

Re aria-sort="none", I was on the fence about this too. This is what the aria spec states:

Authors SHOULD only apply this property to table headers or grid headers. If the property is not provided, there is no defined sort order. For each table or grid, authors SHOULD apply aria-sort to only one header at a time.

And aria-sort="none" is defined as:

There is no defined sort applied to the column.

I read that to mean that if the attribute is missing, it means the same thing as if the attribute were present with the none value. Additionally, the presence of a control to change the sort order (such as a button) would indicate that a given header is sortable, making an announcement for aria-sort="none" redundant. I can see why a screen reader would want to reduce verbosity in this case.

Thus, I think a lack of an announcement for the none value is acceptable. I'm very much willing to hear your take on this though. Is my logic flawed?

Re the partial result for MacOS+Safari: thank you for clarifying that. I'll add another command object for tabbing to the button with the correct output + result. The end result will be partial because there will be one pass (table navigation) and one fail (tabbing). I think it is valuable to separate these commands for testing and documentation purposes.

aardrian commented 4 years ago

I read that to mean that if the attribute is missing, it means the same thing as if the attribute were present with the none value.

But if the aria-sort attribute should only be on one <th> at a time (third sentence in your quoted spec), arguably its presence on a <th> means it is a different case than its absence and as a result should be exposed.

Which is weird to me, because I think it should be available for all sortable <th>es which I guess suggests the spec authors had a take that more closely matches yours. But that does not seem to track with the typical visual equivalent of sort controls which persist when a column is sortable (and WCAG 2.2 will essentially enforce that).

Additionally, the presence of a control to change the sort order (such as a button) would indicate that a given header is sortable, making an announcement for aria-sort="none" redundant. I can see why a screen reader would want to reduce verbosity in this case.

I appreciate this take.

The presence of a control can sometimes be for other reasons (I have helped remediate tables for clients that have two or more controls in a <th>, and only one of them is to sort). In other words, the presence of absence of a control as a signifier of sortability (assuming a good accName) is not a binary.

Thus, I think a lack of an announcement for the none value is acceptable.

Bear in mind that this means even SRs that do not support aria-sort at all will pass that check.

Which also means I take issue with the 'Partial' for Narrator / Edge and VoiceOver (macOS) / Safari for aria-sort=none since it appears neither of them speak it when the nested control is tabbed but which are still listed as failing.

mfairchild365 commented 4 years ago

Which also means I take issue with the 'Partial' for Narrator / Edge and VoiceOver (macOS) / Safari for aria-sort=none since it appears neither of them speak it when the nested control is tabbed but which are still listed as failing.

That's a good point.

The authoring practices also seem to support your interpretation; see the data grid example where it states. This is what it says:

In example 2, applied when a column is sortable but not sorted.

Some other thoughts:

aardrian commented 4 years ago

The authoring practices also seem to support your interpretation; see the data grid example where it states.

You may not know it, but you are trolling me when you say the APG and I agree.

  • Ultimately, I'd like a 3rd opinion on this (maybe @scottaohara if he has time).

Same, but I was gonna kick it out on the Twitters and see who corrects me for being wrong.

  • Would it be worthwhile to open an issue with the ARIA spec to clarify the intention of aria-sort="none"?

Yes.

  • I'm leaning on accepting your interpretation. If we find out that it is incorrect, we can change the results later.

WFM (which means "works for me", not the more obvious "works from mediocrity").

  • Another thing that is giving me pause: none of the screen readers that (partially) support aria-sort match your interpretation. This may be a hint that they have the same interpretation as me.

This is not an incorrect take. I also think it just as likely they are all wrong (I think lots of things are wrong).

aardrian commented 4 years ago

I could not help myself: https://twitter.com/aardrian/status/1305592964392026112

mfairchild365 commented 4 years ago

Thanks! I was about to reply "please do post on twitter!"

JAWS-test commented 4 years ago

See https://github.com/w3c/aria-practices/issues/1192 and https://github.com/w3c/aria/issues/724

mfairchild365 commented 4 years ago

Thank you @JAWS-test. I think https://github.com/w3c/aria/issues/724 matches my interpretation pretty well.

In summary, there are two major interpretations for how aria-sort=none should be conveyed.

  1. Silence (not sorted and not explicit hint that the header is sortable)
  2. That the header is sortable but currently unsorted

With https://github.com/w3c/aria/issues/724 and the results of the twitter poll, I’m now leaning on the expectation being interpretation 1.

What are your thoughts @aardrian?

aardrian commented 4 years ago

I think https://github.com/w3c/aria/issues/724 shows that there is a gap in ARIA, and the 2012 issue it references (https://www.w3.org/WAI/ARIA/track/issues/524?changelog) with its lack of commentary demonstrates they understood some need, but either did not codify it or unintentionally left it ambiguous.

I think the language at https://www.w3.org/TR/wai-aria-1.1/#aria-sort is oddly binary considering the allowed other value:

Indicates if items in a table or grid are sorted in ascending or descending order.

I think the recent discussion around aria-hidden=false (https://github.com/w3c/aria/issues/1256) suggests implicit default values (ie, a missing attribute) cannot be assumed to be the same as explicitly defined values. Which cuts both ways, of course.

I think this statement from ARIA 1.1 is disconnected from reality given that tables can be (and in the case of my clients, often are) sorted by more than one column (date, then dollar amount; vendor then dollar amount; date then type; ...):

For each table or grid, authors SHOULD apply aria-sort to only one header at a time.

I think the example in that tweet conversation about how unsorted but sortable columns expose themselves in Excel (they announce as unsorted as opposed to not at all) is informative (prescriptive or not is a different discussion)

I think the survey shows a pretty even split in expectation from humans who or may not be screen reader users (there is no way for me to know other than my follower cross-section and boosts).

To summarize for the court, I see ARIA 1.1 has an opinion about the number of aria-sort attributes that should be in play, but since it does not correspond well to reality I think that is unnecessarily prescriptive instead of descriptive, and I lean toward the latter. Given my other points (such as developers having to convey sortability in solely one of the four allowed states), I am still in camp announce.

mfairchild365 commented 4 years ago

All wonderful points.

Floating an idea: two assertions for aria-sort=none

  1. MUST convey the none value either by not announcing any sort information or by indicating that the header is unsorted but sortable
  2. SHOULD convey the none value by indicating that the header is unsorted but sortable

In essence, silence is minimally acceptable but explicit feedback is preferable.

Thoughts?

JAWS-test commented 4 years ago

I think this statement from ARIA 1.1 is disconnected from reality given that tables can be (and in the case of my clients, often are) sorted by more than one column (date, then dollar amount; vendor then dollar amount; date then type; ...):

See https://github.com/w3c/aria/issues/582 and https://github.com/w3c/aria/issues/283

aardrian commented 4 years ago

@mfairchild365

In essence, silence is minimally acceptable but explicit feedback is preferable.

I find your suggestion… intriguing. I am on board with it.

mfairchild365 commented 4 years ago

@aardrian I deployed the changes. https://a11ysupport.io/tests/tech__aria__aria-sort

Can you please take a quick look? Is it acceptable to you? I know it may not be ideal, but hopefully, we landed on acceptable.

mfairchild365 commented 4 years ago

@aardrian I'm closing this issue, but please feel free to comment if you think anything still needs to be done.

aardrian commented 4 years ago

I missed your other note, but yeah, acceptable.

aardrian commented 4 years ago

Thanks for holding my hand through this, BTW. And all the fixes, test creation, other platform tests, and so on, which make this more your effort than mine.