Re: ARIA editors meeting 2023-06-12 - minutes

Hi everyone,

My notes from today's call are below.

Best,
Peter.

Present: James, Daniel, Peter, Matt,
Regrets: scotto, spectranaut

pkra: Explore concept/styling for direct advice for how AT/screen readers
should interpret certain aria roles/values
https://github.com/w3c/aria/issues/1942
... could we have some background?
jamsn: spec always shied away from it; couldn't test it well enough
... requirements are difficult to phrase  (e.g., in xyz mode, do ...)
... I feel the idea would be to have something in the spec that's easily
identified by AT
mattking: we have aria-AT now and I think we should leverage it.
... wondering about the scope of the issue
... are just asking for styling right now? Leave it to editors?
jamesn: probably. We can't really do MUST though some might want that
mattking: I suspect SHOULD would already be quite strong
... for aria-at SHOULD would be very helpful
... one concern I have on the scope of this
... if some ARIA statements have AT-related SHOULD and others don't
... then we have aria-at tests for features where they're silent
... will this lead to expectations of "you can't have that without a
reference in the spec"
... not sure that's a good direction for the specs
... if there was an early section (e.g., Sec 4?) of the spec where we
discuss what you can say about roles
... maybe we could add a "class of requirements" related to AT if we can
say something generally about them that would say something about their
optional nature / scope / intent
... if we just have 1 aria feature that has this, the  spec will feel out
of balance
... do others feel that's a valid concern?
jamesn: yes if it's really just 1/2 things. But with a note in the early
section and TODO marks in the spec, it seems doable
daniel: in another group there's been objections against the W3C specs
going beyond the web
... need to be careful not to provoke this reaction
... but we should reach consensus here
pkra: could we get a group of regulars from AT vendors
... gauge their interest, get their feedback
... seems like both sides have something to gain
mattking: aria-at is definitely trying to do this
... e.g., dialog discussions at TPAC
... things are changing enough to maybe have an opening
... shouldn't be too often though
pkra: right, e.g., quarterly
mattking: right many people are interested, topical updates might be good
james: very difficult but perhaps there's a chance if we offer specific
items, e.g., "new things in the spec"
pkra: right, slow but regular to keep things
mattking: shouldn't try to create a multi-headed monster
... keep it focused. track and document requirements
... spec shows what the current status is at some point
... finally ask them for whether they agree on it
jamesn: back to editors
... do we agree that we should have a way to do this?
mattking: right now we have UA and author requirements
... do we have something else?
pkra: we have some lingering AT statements
jamesn: somewhat a UA
mattking: but we need to be careful
... so we'd need a third class
... in other specs, do we have classes of requirements like this?
jamesn: I think so. Closest example: tracking vector that's now required
and highlighted in a special way.
... makes them easy to find, easy to surface
mattking: could we pull them out? UA/authors/AT?
jamesn: I wouldn't do authors because that's a lot of prose
mattking: so like separate paragraphs?
... I do like asking for clear UA requirements separated out in PRs
jamesn: yes. It'll be hard to untangle UA/authors.
mattking: it's really useful to separate these for reference
... if we have some editorial guidance for this, then the paragraphs
themselves could be "normative paragraphs"
... does respec have something for this?
jamesn: not directly but similar stuff
... both respec and bikeshed have something nowadays
... not extendable so we could request
... or we could follow their examples
mattking: we already have role and property ref
jamesn: exactly
... we need to prototype something
mattking: I'd suggest not just 1 style but all 3 styles immediately
... and not just visual
jamesn: I'd like a prototype that can be extended that way
mattking: right. just don't paint yourself in a corner
jamesn: right. e.g. background color could get difficult
... e.g., https://speced.github.io/bikeshed/#tracking-vectors //
https://infra.spec.whatwg.org/#tracking-vector
pkra: I'd like to try to pick up on the visual cues for notes, examples etc
mattking: btw can we fix notes?
pkra: I have made some progress. Need to find time to get back to it
jamesn: we have all this non-standard respec stuff, and I'd like us to move
away from that
pkra: can we move the issue to common?
jamesn: makes sense
mattking: let's also add editorial guidelines
pkra: those go more into aria, right?
mattking: right
pkra: then new issue for design


pkra: moving to * https://github.com/w3c/aria-common/pull/94 &
https://github.com/w3c/aria-common/pull/49
... how do others feel?
jamesn: I feel linting is affecting files that only a handful of people
touch
... if we have editor's owner take this as a task
mattking: in APG, for a while, we had github configured to block merges
... disabled it because only Emma and I merge things
... sometimes things fail but we have to merge
... and it's worse if you can't merge
jamesn: sounds good
mattking: for prettier on HTML source, I've been annoyed with some of the
linebreaks
... e.g. middle of link tag
... I like "semantic" line breaks - put a sentence on a line
... it's just a personal preference, linebreaks in prettier can be
difficult for me
daniel: yeah, can be
jamesn: I'd like to see the effect on the aria spec
pkra: I'll make a
mattking: on APG we deactivated linebreaks
pkra: maybe start with whitespace
pkra: ok, then I'll merge Nick's, make prettier PRs for aria and...
mattking: one of the AAM?

pkra: on contributors.md, maybe not enough time
mattking: yeah, let's find a better way
jamesn: just github seems good
... maybe some extra people. Maybe get them to do a thing on github
mattking: reviews and comments included?
jamesn: should be possible
pkra: do we worry about drive-by comments?
jamesn: still better than what we'd have
pkra: maybe we can hide them as off-topic
jamesn: let's keep what respec does as much as possible
daniel: last I checked it was PRs
mattking: github has changed its approach, too
... feels like respec might want to match what respec does
jamesn: I'd imagine they use a github API, so probably yes



Am So., 11. Juni 2023 um 12:37 Uhr schrieb Peter Krautzberger <
peter@krautzource.com>:

> Hi everyone,
>
> Sorry for the late email. Below is the agenda for tomorrow's meeting.
> Please let me know if you'd like to add anything.
>
> - Explore concept/styling for direct advice for how AT/screen readers
> should interpret certain aria roles/values
> https://github.com/w3c/aria/issues/1942
> - Continue discussion around future of aria-common
> https://github.com/w3c/aria-common/issues/61 etc
>
> Best,
> Peter.
>
>