<janina> scribe: melanierichards
joanie: the CFC decision has closed, thanks to melanierichards for providing Edge's test results
<joanie> https://w3c.github.io/test-results/accname/
<joanie> https://w3c.github.io/test-results/accname/complete-fails.html
joanie: if you go to complete fails, there are none!
<joanie> https://w3c.github.io/test-results/accname/less-than-2.html
joanie: if you go to "less than 2", there is only 1.
<joanie> https://w3c.github.io/test-results/accname/all.html
joanie: good news is lots of green, lots across the board. The bad news is there's lots of tests where we only have two passing, Webkit GTK and Safari. What I plan to do is look for the cases where we have 5 failures, and try to reduce the number of failures so that when we're ready to officially exit CR, we can exit more strongly
<jamesn> https://github.com/w3c/accname/milestone/1
jamesn: there are 2 open issues against 1.1 that we either need to resolve or move to 1.2
<jamesn> James to ping Bryan about these
jamesn: they've released a prelimary schedule, they've assigned us Monday and Tuesday, but we're trying to move to Thursday and Friday. So don't make travel plans yet. Mon/Tues clashed with other accessibility groups
<jamesn> https://lists.w3.org/Archives/Public/public-aria/2018May/0005.html
<jamesn> https://github.com/w3c/html/pull/1133
jamesn: APA have requested we review an item from HTML 5.3. Steve's ARIA document vs. HTML spec. There's a PR that shows the changes, it would be awesome for someone to take that on and review the changes
joanie: please ask Bryan to check that out
jamesn: I took a quick glance,
most of them don't seem problematic
... we should still take a look in a bit more detail
Janina: looking for feedback for the last full week of May
jamesn: no objections to the CFC, so we're ready to move our charter to management for the next step
<joanie> "The ARIA Working Group will review, on an ongoing basis, deliverables from other Working Groups where they overlap with the ARIA Working Group scope."
<joanie> The Working Group also expects to collaborate with other groups which produce ARIA and/or Accessibility API Mappings specifications to ensure that all ARIA modules and Accessibility API Mappings specifications are consistent with one another regardless of the producer. These specifications may include:
<joanie> Digital Publishing WAI-ARIA module, a deliverable of the Publishing Working Group
joanie: still want to keeping thinking about this language
<joanie> HTML Accessibility API Mappings, a deliverable of the Web Platform Working Group
<joanie> SVG Accessibility API Mappings, a deliverable of the SVG Working Group
joanie: if we agree that on an editorial basis it doesn't belong in that section, we're going to remove that second sentence "The ARIA WG will review..."
joanie to delete that sentence
<joanie> https://joanmarie.github.io/test-results/graphics-aam/
joanie: I would like to do a CFC to transition Graphics ARIA and AAM to proposed recommendation
<joanie> https://joanmarie.github.io/test-results/graphics-aam/all.html
joanie: we can do all the
graphics aria testing by looking at the mappings, there's
nothing that can't be done by testing through Graphics AAM.
Thanks to melanierichards for getting us the Edge results! The
only thing that's not up to date is that Aaron Leventhal of
Chrome did the implementation, in Canary those are no longer
total fails. So I need to update the test results
... we're green across the board! These are ready to go to
PR
... later today I'll send out that CFC
<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity
<joanie> https://github.com/w3c/aria/pull/761
joanie: there is a section called "things which require a new role", under specific, blockquote, caption, and paragraph had a couple other items. Created a new PR for just these 3
<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/761.html
<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/761.html#blockquote
<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/761.html#caption
joanie: [last item should read: there was a PR that had blockquote, caption, and paragraph, and had a couple other items]
<joanie> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/761.html#paragraph
joanie: these are for parity, simple text elements. One of the reasons it's worth getting these in is that these 3 roles will be easy in the new workflow to do mappings in CORE-AAM, do a couple tests, ask for implementations. When we go to first public working draft, we'll have a couple
<jamesn> https://www.w3.org/WAI/ARIA/workflow
<jemma> do we have url for this issue/discussion?
<jamesn> https://lists.w3.org/Archives/Public/public-aria/2018May/0047.html
aaronlev: the goal was to support
a much more accessible Google docs to use semantics rather than
current live region approach, which doesn't really work for
Braille. I talked to the docs team and said let's find a
semantic way of doing everything. Someone pointed me to
Microsoft annotations proposal
... good proposal but not really sure we really need a new
relation. aria-details seems like a good solution. Let's say I
want to have some commented text. I have some text, someone
highlights a word, has a comment. Have a span with aria-details
on it, pointing to another element on the page, that element
has some new role like "annotation-*", use motivations from Web
Annotations.
... But they don't necessarily have to be that, could also be
"footnote". This proposal wouldn't require much change from
user agents today, instead of adding a lot of new things to
markup today. Ran this by SR vendors and they liked it
(refer to email for details)
aaronlev: another example:
changes in a word processing environment. if a word change,
struck through and you can add more information about the edit
made
... AT can allow user to navigate over to comments section and
back
<joanie> https://w3c.github.io/aria/#note
<jemma> https://www.w3.org/annotation/
joanie: I agree that this need should be addressed. the solution using aria-details sounds like a reasonable approach. I'm wondering if there needs to be a role, because we already have a role called note. Authors would be told to use these 2. The question is: why is the note there? That is the motivation. It wouldn't necessarily need to be limited to annotations. Wondering if what we want is an attribute instead of roles
aaronlev: we could instead add an attribute, would not oppose. I looked at the role of note, looks like it's part of the originally authored content, instead of a third party commenting something. you could potentially have a comment existing inside something with role note
joanie: a single role called annotation, and then a property that tells you the nature of the annotation. We don't want to have a role explosion if they're all mapping to the same thing. It's easier to expand an attribute with a new value if we forgot to deal with something
melanierichards: +1 to joanie's comment
aaronlev: don't disagree that a
property would work, might be easier to implement the role
proposal
... people wanted to consider web annotations motivations as
something we can reuse (they have the gerund, -ing
format)
... role="annotation-describing" etc pattern
Janina: there's been a minefield of years of trying in various ways on how to annotate various things. text included, but also binary objects. we need to be careful about what this does/doesn't cover. let's get publishing, math, and if it's relevant, graphics people involved earlier. there's a larger need. I'm not clear on what this all covers
<jemma> I agree with janina +1
<Zakim> joanie, you wanted to ask if instead of a role, it could be a property
<Zakim> janina, you wanted to ask about scoping constraints, i.e. just ext spans? binary object as well?
tzviya: I heard Aaron acknowledge that properties exist in the web annotations model anyway. The fact that this exists already is something we need to be very cautious about. We should talk to someone like Hypothesis to see how they've accessibly implemented comments, strike through, etc. someone like [name missed] might be able to help you a lot. Trying to incorporate 2 models to do the same thing will be very frustrating.
<jamesn> https://www.w3.org/TR/annotation-model/#motivation-and-purpose
tzviya: the web annotations motivations is very important to look at, and if we're doing something duplicative, that's a dangerous area
aaronlev: that's why I used a
subset, to not conflict. Didn't use the full set
... thought it was better to align to motivations
<jemma> one of co-chairs of the web annotation working group is Tim Cole from U of Illinois and we can ask some info if needed.
aaronlev: one of the reasons why I came to using a role for these is to better link annotation to the element it describes
jamesn: we need to discuss it more, I'll discuss folks in PDF
<aaronlev> Here are the motivations from the annotations vocabulary: assessing, classifying, commenting, describing, editing, highlighting, identifying, linking, moderating, questioning, replying, tagging
aaronlev: I thought describing what aria details is usually doing by default
joanie: a couple of these look helpful for notes, I don't know that we want to change the role if there's a reply in a threaded discussion. I recognize and like the need, and like the concept, but leaning towards an attribute
jamesn: leaning towards an attr too, these all seem useful but don't want to have 10 roles
aaronlev: I don't know how the footnote case fits in
tzviya: we originally had distinct roles for each kind of bibliographic reference, note reference...a lot of roles, a lot of the implementers found that it was too much processing. In HTML there are rel values that take care of some of this. A lot of the roles might look similar, so you can accomplish more with label than you think
aaronlev: label not desirable because Braille rendering wants to know if commenting, etc and want to have a special symbol for this
joanie: dPub AAM lives in the
ARIA WG, Tzviya, keeps us posted on updates
... if it's an attribute it still has to wind up in the
mappings. if the role proves to be the right way to go, we'll
have to do mapping there too. Tzviya has a spec in her working
group that we think will only have errata, we want a heads up
if we need to make changes in dPub AAM
aaronlev: the original Microsoft spec talked about code breakpoints, didn't look into that. aria-detailsType="breakpointing"??? We can have -ing ones that we are borrowing, and some that are ARIA's own
jamesn: more offline discussion is needed with aaron
aaron: happy to continue via email, want to have something SRs can get working sooner rather than later
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/708.html
jamesn: IDL reflections ready to go into editor's draft of the spec. don't think we need a CFC for that, please review it. all the new stuff is in section 8, if you don't believe this is ready to go, please speak up over email in the next day
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/lol// Present: Joanmarie_Diggs janina jamesn melanierichards JaeunJemmaKu Tzviya aaronlev MichaelC Regrets: IrfanAli JonGunderson Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Date: 17 May 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]