<scribe> scribe: MarkMcCarthy
jamesn: pretty sure there's no
new issues, but i'll double check
... blocked any issues that are pending our discussion
<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-01-03+
jamesn: role parity ones we can
ignore, they're 1.2
... no new aria issues since last week
<jamesn> https://github.com/w3c/accname/issues/42
jamesn: MathML and accname, issue 42, anyone know anything?
joanie: history of this issue:
some screen readers, jaws and orca, don't work well. the other
crux of the issue is name calculation
... calculated labels for each of those exponent and fraction
spaces weren't the same
... for interoperability, we don't want screen readers to have
to sanity check everything
... my response was i'm not changing anything in orca, here's
the accname spec. thought he'd leave, ,but he filed an
issue
... i think there's a point to what the filer is saying, and
maybe the fix is if you're embedding complicated markup, try
aria-label
jamesn: if that's the case, that wouldn't be an accname fix?
joanie: well it would because it
might lighten up the calculation
... it's complicated to extract an accname since there's lots
of text and other elements, thus the confusion of exponent and
fraction 23s
jamesn: what do you propose doing?
joanie: something in 1.2, namely
deciding what we want user agents to do
... i think we want authors to supply an aria-label, and
mention that user agents aren't expected to calculate this
bg: do you know what the format is? text inside the tag or...?
<pkra> ;-)
<pkra> msqrt
joanie: there's a bunch of tags, some with text inside, some with no text but depending on the tag symbols are rendered
bg: i thought how it was meant to
work...it's almost like a composite widget
... i thought there was a note that mentioned something about
putting an aria-label on it?
jamesn: just triage! just wanted to make sure bg was here to have some idea on future fixes
joanie: presumably, we'd have to come up with something that'd translate sqrt to "the square root of..." anyway moving on
<pkra> https://github.com/w3c/aria/issues/765
pkra: it seems like one of the driving forces for this is braille, so i wanted to point out this issue
jamesn: i can put that on agenda for next week, unless we have time at the end of the meeting
<pkra> :)
<pkra> in a friendly way!
joanie: we might want to move that to 1.3, but if possible 1.2?
jamesn: can't put it on 1.2, unless people do a lot of work
jamesn: last week we had an issue
raised that everything wasn't getting CfCs created? possibility
people might comeback to us and say "we weren't aware"
... joanie and I discussed; our opinion is that we have lots of
places in the process where people can see what's going
on
... what we thought we might want to do as a policy is that
when we have something that needs changes, we have a
workflow
<joanie> https://www.w3.org/WAI/ARIA/workflow
if we have many of these items ready, we send out a note that these items are being added
mck: remembering the history of
the past where we had a multiweek discussion of decision policy
and that's when we set up list for CfCs and then every
resolution went out for 48hr CfC
... what stimulated that were objections coming too late
... we got used to having CfCs, then it went to current process
which is no CfCs until CR
... because we took away CfCs for working drafts
<aaronlev> Joining late ... apologies
mck: in the current workflow, do
we have any activities when we decide to put something in? it
seems like we stripped some functionality
... i don't know where the formal objection points are and i
don't want us to move backwards where CR was a headache
joanie: we might still be in
danger of late objections, but we've got platform mappings,
owners will be aware
... we have to make test files, execute tests, file bugs,
direct authoring guidance
... we don't put it in working draft... unless we meet exit
criteria. i.e. passing examples and resolved bugs
... notification is a way to address your concerns mck, but i
don't think we'll roll anything back
mck: either the implementation is there on a test or a bug that we're making sure we get a response to
joanie: yes
... the only changes we have made this release cycle are
changes that don't change implementation or a couple
roles
... we didn't need a positive response on the bug because it
was fixed for implementation
... i'd look at bugs and if we didn't have positive response it
wouldn't make it
siri: could we have a page where everyone in the public could see what was changed? a changelog
jamesn: in the editors draft we have changelog
<joanie> https://w3c.github.io/aria/#changelog
joanie: indirectly, there's a
changelog in the working draft
... everything has a changelog. what'd you find missing?
siri: so many things might change
it's difficult to know what has specifically changed,
especially if it's a small detail like a sentence or explicit
wording
... wcag and aria have so many rules, roles, etc., it might be
hard to keep everything straight.
... is it possible to add "we changed XYZ this month," each
month?
jamesn: if there's something else you'd like...
joanie: if this is something you feel we aren't doing adequately, it'd be great to have you volunteer
siri: i can, but i'd need help
mck: is it a matter of having a table with "here's the change, when, a link to the bug," or something like that? with tracking?
siri: yeah, something that provides easy tracking and scanning through changes, versus lots of text
jamesn: that's what the changelog is meant to be
siri: okay i'll look into it
jamesn: in the case of CfCs, it's either people +1ing or asking redundant questions; just noise. if it's more useful than not, i'm happy to keep
<siri> Have another meeting, dropping from the call
mck: question of logging bugs
with implementation, that's important and maybe I was
forgetting
... maybe in the announcement, say it's currently implemented
in browser XY, and a summary of changes. maybe siri could add
that summary into a table? that'd be cool!
jamesn: a webpage that says what we're working on that'd be cool
mck: mining through issues is hard, but if you wanted to see tests, PRs, etc., having that on a table would be amazing
jamesn: it would, but i don't
know how it'll be kept up to date
... if everyone's happy with proposal to have announcement for
BIG changes, we could do that
mck: +1
<carmacleod> +1
<pkra> +1
jamesn: aaron, could you update us?
<aaronlev> hang on finding my mute utton
aaronlev: i think the update was
that we resolved everything, maybe some minor issues in
document and hyphen usage
... other than that, I'd like to know next steps
mck: in that proposal, we did propose an abstract annotation parent role yes?
aaronlev: yeah, that's true
<jamesn> https://github.com/w3c/aria/wiki/ARIA-annotations-draft-proposal
<jamesn> & issue https://github.com/w3c/aria/issues/749
mck: just about the hyphenation... if we're listing as a hierarchy, I'd hope it's clear. i don't think there's anything that sounds close to an existing role?
aaronlev: i'd like to solve the
broader problem of so many roles. what i liked about the dpub
roles is that they -were- hyphenated, i knew they lived
somewhere different
... similarly, I wish there was a quicker way to find the list
of roles, or a role in the list of roles, in the spec
... might not be the best solution, but the spec is gonna grow
so what can we do to keep things in consumable packets?
mck: memorize it
... no, i think you have a good argument. i wonder how it might
be improved, not married to any one way
... in practice, i wonder if people care how it's laid out,
rather than just how it works
... i wonder if AT people would have anything to say about
this, given how they give the information to users
aaronlev: my thought is that at
one point people will be overwhelmed by a big update to the
aria spec
... but if there's these annotation hyphen things it might be
easier
jamesn: also might lead to less misuse
mck: some people might agree, some might say otherwise
<pkra> what could go wrong.
aaronlev: big problems with aria
are misuse and lack of understanding
... i think i've read graphics module is expanding, and i'm
happy that the new items are going to be graphics-something
mck: you're warming us up to this aaron
jamesn: i convinced myself that i'm fine with hyphens
aaronlev: so what do we do?
jamesn: i'm fine going forward, you'll be doing the lifting? doesn't fit into 1.2, so you'll need to do a lot
mck: is annotation something
like... does it all need to go in at once? would we do a PR for
each new role or is it something we can land all at once?
... any reason that some might get added some might not?
aaronlev: i've never done any spec editing before, but I really want editors to be accessible
joanie: should there be an annotation spec like we have dpub and graphics spec?
mck: like a module?
joanie: don't have to decide, but getting back to mck's question of the next step, next step is to set up a repo and make aaronlev the primary editor so he can make all the changes he wants
mck: isn't that a lot of work though? rather than just piggybacking on aria?
joanie: i don't think so, other
than what MichaelC needs to do. we still need tests,
implementations, results, etc.
... doesn't really matter what document it's in
aaronlev: i'll need lots of help
joanie: we can! but don't want you blocked out
<aaronlev> thanks @bigbluehat
joanie: bigbluehat said he'd be happy to help! there ya go aaronlev
jamesn: sounds like a good way forward
aaronlev: on another note, there used to be wording in aria spec that you could create own roles, but no guidance
MichaelC: that was when aria was XHTML, we don't support now
jamesn: aaronlev did you want to discuss with me, joanie, maybe bigbluehat if amenable, MichaelC about next steps?
aaronlev: yep that'd probably be good
mck: we don't have graphics and dpub in in aria practices
jamesn: we're free to choose what
to do
... i'll contact everyone for how to discuss, email
forthcoming
jamesn: can we punt to next week or end?
all: yes
jamesn: joanie and i talking
about tentative schedule for F2F
... not set in stone, but a possibility! thoughts?
joanie: first week of may for me is ok too
jamesn: sometime at one of those
two times. let us know your thoughts and plans!
... looking for a host or adobe probably could, but we're
flexible
mck: simple to host here if you
need a host, but adobe might be logistically better
... if there aren't hotels close to adobe, maybe menlo park
-isn't- much better
bg: san fran office might be able to host as well
jamesn: plenty of hosts! but can we get folks to come? goal is to get through as much 1.2 as possible
<jamesn> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity
jamesn: plans for regarding role
parity page: we have the section for specific role
elements
... where i couldn't find existing issues, i logged
issues
... need to start getting things in and issues worked on
... plan is that we could ask for volunteers, get some initial
drafts, -should- be simpler than generic
... since we're short on time, does anything jump out at
anyone?
<jamesn> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#specific-role
joanie: i want to do meter!
... shouldn't be controversial, and many authors probably want
to make nice ones
jg: about label, do we want to recreate functionality or...?
joanie: main reason is that this for role parity
mck: ohh so they have to have the same functionality etc. anyway. you'd use the non native label because you -want- to create that functionality and don't want to use native
joanie: i assume some toolkits might take advantage of these and make-it-work
jg: it seems like label isnt something that needs a role, what's the purpose? currently any special mapping?
joanie: yes, some things
jg: oh okay
joanie: i'm not a custom component person, but they still need parity
jamesn: other questions?
HarrisSchneiderman: yeah it was answered
jamesn: we're doing this because we said we would
HarrisSchneiderman: some of these look awesome
jamesn: i'm going to ask people
to look through these and, if comfortable, please take one and
write spec text
... we can get PRs made and discuss in more detail
jg: i'll try to do label then
joanie: the other thing that
makes parity easier is that we need HTML parity. e.g. there's
already some info to go off of.
... e.g. our caption role is about the same as HTML caption and
figcaption. we're basically stealing language
carmacleod: i tried to do that!
[laughter]
joanie: the non-generic ones should be easy. entire goal is to have same functionality that exists in HTML
HarrisSchneiderman: definition list role is probably gonna be difficult, i'm not volunteering for that one!
jamesn: if anyone finds one that looks easy, please take it and do it
<pkra> bye!
jamesn: thanks! sorry we didn't get to text separation, we'll take it up next week if we can
RRSAgent make minutes
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/workplan/workflow/ Succeeded: s/notificiation/notification/ Succeeded: s/misue/misuse/ Present: jamesn Joanmarie_Diggs HarrisSchneiderman MarkMcCarthy MichaelC jongund pkra carmacleod Stefan melanierichards matt_king Found Scribe: MarkMcCarthy Inferring ScribeNick: MarkMcCarthy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 10 Jan 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]