search

w3c / aria-at

Assistive Technology ARIA Experience Assessment
https://aria-at.netlify.app
Other
154 stars 28 forks source link

Create tests for native widgets in HTML #56

Open zcorpan opened 4 years ago

zcorpan commented 4 years ago

I think it would be useful to consider testing the behavior of native widgets in HTML, in addition to APG design patterns. It usually is easier for web developers to use a standard element and get accessibility for free, compared to rolling their own widgets with ARIA. There are also some widgets in HTML that are not in APG (e.g. color well).

For example:

Some challenges:

mfairchild365 commented 4 years ago

I think this would be a great long term goal for this group/project, however it is currently out of scope. I’ve been tackling this aspect over at a11ysupport.io - happy to get feedback on that.

mcking65 commented 4 years ago

Yes, super useful, but currently out of scope.

We want every APG pattern to have a "as little ARIA as possible" version in the future. Then, that will naturally bring this into scope.

But, that is beyond APG scope at this time. Right now, W3C doesn't have a single working group with that kind of scope. We force people to wander all over the place and consult a massive list of resources to get a full picture of how to do accessibility, trade offs of different approaches, etc. So, the long term strategy here is to 1) get APG complete in its current scope (cover all ARIA), 2) Change APG from a Note into a WAI web site (like the tutorials), and 3) form a joint task force with other WGs to develop a single, more comprehensive resource based on that WAI site.

In the meantime, the APG and ARIA-AT will be integrated in that WAI site.

Massive amounts of work here, but it will be worth it! Someday, developing for assistive technology users will be as efficient, robust, and well understood as developing for any other cohort of users. All this is one dimension of that future reality.

zcorpan commented 4 years ago

From #111 - @cookiecrook gave this same feedback, to also test HTML widgets.

zcorpan commented 3 years ago

@mcking65 I think we can decouple the scope of APG with the scope of aria-at. That is, I think it can make sense to include tests for things in HTML (e.g. simple checkbox), CSS (e.g. CSS generated content), and maybe even Open UI (e.g. <popup>), in aria-at, without having that be blocked on the scope of APG.

It's a new year, so maybe we can discuss the scope of aria-at again. :)

boazsender commented 3 years ago

+1 @zcorpan, especially seeing as Open UI is driving implementation of accessible defaults in web browsers, based on APG.

We can't include those new Open UI elements in APG before they are stable, but I think it would be strategic to include them in ARIA AT and test AT rendering of those elements as soon as they are implemented.

mcking65 commented 3 years ago

The scope of APG is growing this year in tandem with the APG redesign project. So, rolling in native HTML is just around the corner with our current plan. And, that will also pull in everything open UI!

So, it seems we might already be reasonably aligned here.

One reason for prioritizing ARIA patterns in the meantime is because that is where we see the most confusion that has severe impact on users. Enabling high-quality accessibility for patterns that cannot be built with native HTML unlocks a huge swath of the web that is pretty much out of reach for a lot of people.

boazsender commented 3 years ago

So, it seems we might already be reasonably aligned here. That's great!

For <popup> (the sub-part of select menus that Open UI is working on) does that mean we'd want wait for for design pattern guidance for it to be added to APG before we'd add ARIA-AT tests for it? Would we be okay with the tests landing prior to the design pattern/guidance?

I can suggest the outcome of this question into the working mode being developed in https://github.com/WICG/open-ui/issues/197.

One reason for prioritizing ARIA patterns in the meantime is because that is where we see the most confusion that has severe impact on users. Enabling high-quality accessibility for patterns that cannot be built with native HTML unlocks a huge swath of the web that is pretty much out of reach for a lot of people.

That makes sense. I'm also thinking that having early tests in ARIA AT could help ATs not diverge on interpretation of the Open UI elements coming down the pike. Just a thought, perhaps worth some discussion in the future.

For what it's worth, I know that Open UI is drawing heavily from existing ARIA Practices, and plans to align with the ARIA community on AT rendering behavior for all new elements. So writing the tests would definitely come after we had alignment on desired rendering behavior.