Minutes from brief meeting with Chris Heilmann / Microsoft about potential for adding ARIA-in-HTML validation into Edge Developer Tools

For context, this meeting was partly to explore possibility of having
ARIA-in-HTML directly integrated into Edge Developer Tools to provide an
additional implementation for the spec to go to REC eventually.

Topic: Accessibility tooling in Edge/Chromium
Date: 3 Sept 2020

Present:

CH - Chris Heilmann (Microsoft)
SF - Steve Faulkner
PHL - Patrick H. Lauke
GL - Gez Lemon
SO - Scott O'Hara

Scribe: Patrick H. Lauke

(setting the scene about reason for the meeting: from Chris' side, getting
feedback on current and planned accessibility-related tooling; from
Steve/Scott/Patrick's side, having an additional implementation of
ARIA-in-HTML)

CH: moved from DevRel into production role, principal manager for Developer
Tools in Edge (taking what came from the Chrome/Chromium side and improving
it).

(showing us improvements to Edge developer tools)

New "Issues" pane powered by axe-core and webhint - more useful than console
with its traditional errors/warnings

Showing source (for elements in flex) (numbered overlay on page) - requested
by Adrian Roselli at Web We Want.

Rendering pane - "Emulate vision deficiency" etc. Problem with terms being
obscure / confusing to developers who are not already familiar with them.

In Google (not downstream yet) there's now accessibility in the element
inspection tooltip. Annoying: can't copy from it / tooltip can't be
selected.

Possible future additions: functionality to show the alt text?

Accessibility pane was always a specialist tool - doesn't tell me what I
should do with it.

SF: one of the things i find with tools is that there's often information
missing. relationship information, for instance in tables (the relationship
between the current cell, and how it's given context by row/column headers).
exposed in the accessibility tree, but not surfaced by devtools directly.

CH: for form labels, aria-labelledby, etc it works though

SF: yes that currently does. devtools also generalise over some of the
platform-specific idiosyncrasies of accessibility APIs.

CH: does Accessibility Insights expose it?

SF: not tried it, it might.

CH: table inspector might be a good idea.

In terms of accessibility testing, do people use 3rd party tools more, or
developer tools?

SF: I use both developer tools and 3rd party tools, for things not well
displayed. I tend to use Firefox accessibility tools more because it has a
separate panel for the accessibility tree.

CH: not just a list like we do. Is that the developer version of Firefox or
the in-market one?

SF: regular one.

CH: what I like in Firefox as well is the grid inspection. Showing a little
label of grid when something has a grid. Thinking of doing something similar
for ARIA. Maybe even showing errors like missing ALT etc directly in the
source view/elements view.

PHL: i always liked in Firefox devtools how it shows directly in the
elements panel/DOM view where event handlers are hanging from (with little
tags/tabs on the element). would be nice to get this, as well as things for
errors or use of ARIA. but then make it toggle-able so it doesn't look too
messy. But it would go a long way towards making this information more
immediately available, rather than shuttled off into a separate specialist
"Accessibility" panel.

SO: would be nice to surface errors/notifications more directly. Issues
panel you showed is already a good step in the right direction.

CH: i'm also responsible for the integration stuff of  devtools and external
tools (like VS Code integration). what I like there are things like webhints
integration directly in VS Code, and it tells them what's wrong before they
even save, rather than afterwards.

SO: that would be great, to hook into it for ARIA-in-HTML at that stage as
well, rather than later.
With some of the stuff in ARIA 1.2 there's some work for us that's not in
public branch yet. e.g. prohibiting aria-label on things without specific
role. would be good "should not"s that could be flagged at the development
stage already.

SF: dropped an example of a rule that's implemented in
validator/aria-in-html, but not picked up by axe.

```
example error picked up by validator but not flagged in axe (for example)
<button><span role="button">test</span></button>
```

SO: stuff like that shouldn't even be a thing we need to worry about, but
there we are. would be good to flag as a warning/error.

CH: this even opens up whether or not the parsers in browsers should choke
on this or not, or error correct, as it does with broken HTML.

SF: it's trickier to get this sort of thing through in the parser side of
things. at this stage, it's probably a good first step flagging this up as
an error in developer tools etc, as it does with the w3c validator already
now (which has the first implementation of this)

CH: so what Gez has written, what's the new thing it does?

https://github.com/ThePacielloGroup/WAI-ARIA-Usage

SF: the wow factor is that it's a bookmarklet / specific implementation of
the author conformance requirements, that are already built into the w3c
validator. it checks that you used ARIA-in-HTML in the correct manner (per
spec) and flags up when you haven't.

CH: are these rules available via an API, or hardcoded into the extension.

GL: that was done using a JSON file, so it can be extended/changed without
needing to recode the whole thing.

CH: and that's on github?

GL: yes.

CH: this is something that could be an extension of VS Code as well. doing
this sort of check at the coding/development level might make even more
sense.

Did you find that doing it as bookmarklet you were having problems, e.g.
running it on sites like twitter?

SF: yes, same origin stuff.

CH: way around it is to package up as actual web extension.

SF: yes we're looking into this. also will have integration into ARC.

CH: will send this to Rachel (?). 

Axe is great, but it causes issues with running 3rd party resources /
API-connections in environments like internal networks/firewalled
environments. So anything we can grab and package directly into our tool
would be better.

How is the process once the spec changes?

GL: no automation/process, need to manually go in and change.

SO: we plan to change this to a process, so that once the spec is changed,
we also generate an appropriate JSON.

CH: this is all good for an initial discussion. we'll take this internally.
also good to hear feedback on our additions. we're always keenly aware to
user test first before we roll out things, as developer tools are already
getting overwhelming, so just adding more features is not always the answer.
there's possibility to maybe also collaborate on this aspect with
TPG/TetraLogical for user testing.

Are there any other tools that you think are missing?

PHL: one very specific aspect that has been bugging me for ages: being able
to just "freeze" whatever is currently in the browser. scenarios like
tooltips that show on mouseover, and wanting to show the tooltip then freeze
the page so i can go into elements panel/devtools to analyse this.
currently, this is tricky as the tooltip shows, you try to move quickly to
devtools, but moving the mouse towards the devtools then leads to the
tooltip disappearing again. Yes, if I know enough about devtools, and
JavaScript, I could probably add a breakpoint on the element when the
subtree is modified, trigger the tooltip, and then step through the JS until
the tooltip itself is generated etc...but this requires much deeper
knowledge of devtools, and possibly knowledge of the actual site and the
kind of scripting it uses. Needs to be a much simpler solution like a big
red "STOP" button that, when activated (by keyboard and mouse) just stops
all execution of scripts, all CSS animations, all pseudo-states triggering
.... and just lets me examine the page as it is at that frozen moment in
time.

CH: you can force pseudo-classes in devtools, but yes beyond that it's not
easy to do what you describe.

(wrap-up of the call, with promise to keep conversation going for possible
addition of ARIA-in-HTML related notification in browser devtools, or even
in VS Code directly, similar to webhint integration)




Patrick H. Lauke
--
Accessibility Specialist @TetraLogical
https://tetralogical.com

Received on Thursday, 3 September 2020 15:39:34 UTC