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

Thank you Patrick for taking these notes and sharing them with the WG, 
and to all of you for having this conversation. It sounds like a 
promising start and I hope it will lead to good things.

If there is anything I can do to help, either as WebApps co-chair or 
general accessibility bod, let me know.

Léonie


On 03/09/2020 16:08, plauke@tetralogical.com wrote:
> 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
> 
> 

-- 
Director @TetraLogical
https://tetralogical.com

Received on Thursday, 3 September 2020 16:38:57 UTC