Create tests for native widgets in HTML

[zcorpan]

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:

• <input type=checkbox> (checkbox)
• <input type=range> (slider)
• <input type=color> (color well)
• <input type=file> (file upload control)
• <select> (select-only combobox)

Some challenges:

• The rendering and behavior for each control is for most widgets not tightly defined, allowing browsers (and ATs) to innovate with how they are represented.
• Not all standard widgets are supported in all browsers yet.

[mfairchild365]

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]

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]

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

[zcorpan]

@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]

+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]

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]

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 openui/open-ui#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.