W3C

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

03 Jan 2019

Attendees

Present
janina, jamesn, MichaelC, HarrisSchneiderman, Joanmarie_Diggs, melanierichards
Regrets
Chair
JamesNurthebn
Scribe
HarrisSchneiderman

Contents


<jamesn> chair: JamesNurthen

<scribe> scribe: HarrisSchneiderman

https://github.com/w3c/aria/issues/870

jamesn: I think we should discuss this one (in terms of role parity). Joanie, do you agree?

joanie: I agree with revisiting it but...short answer: idk

mck: This could be a distraction in achieving the goal of mapping all the html elements

jamesn: My fear is that there would be abuse
... 1.2 milestone on this?

mck: No harm in doing so
... If this is needed for an inline tag like strong, em...i don't see how this would be helpful

joanie: I'm in favor of considering things for 1.2 that we all agree that we should do AND that are easy
... after doing lots of work with james craig on role parity, members of group didn't necessarily agree with everything
... don't see how you get parity by eliminating contents of element

jamesn: I'm hearing not 1.2 and we can punt to 1.3
... No need to discuss https://github.com/w3c/aria/issues/867

MichaelC: agreed

<jamesn> https://github.com/w3c/accname/issues/41

<jamesn> RFC-2119 keywords are formatted in uppercase and contained in a strong element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.

<joanie> https://w3c.github.io/aria/#conformance

jamesn: I don't really see the benefit in this...I does come off a bit awkward in the way it is written and it seems a bit over-the-top

joanie: whether or not we need this, I'll leave to michael. We don't have a dedicated section for this but we do have the content

MichaelC: there isn't a formal requirement for such a section but this might turn into a requirement
... If we already have to content, we have a stronger case to create a section for it.
... we don't have to if we don't think it is called for though

jamesn: I don't know how useful it is...anyone disagree?

mck: By "reader" did they mean screen reader?

jamesn: No, the actual reader (person)

joanie: are we doing what is stated there? Maybe that is reason for omission

jamesn: This is just editorial and maybe take it offline / mark it as editorial 1.2 issue

mck: are they asking should you do that? (what is described in ticket)

jamesn: they are saying is it useful to show people how this is done

MichaelC: We should consistently apply this to our spec

<joanie> https://www.w3.org/TR/accname-1.1/#rfc-2119-keywords

joanie: I think this gentlemen is asking: "Why is the paragraph here?" / "Please delete this section"

MichaelC: Theres probably some historic reason for the existence of this content. iirc we got a comment asking for clarification of this

New Issue Triage

<Zakim> joanie, you wanted to say "out of scope and not easy"

Review radio role: removes default value of aria-checked from role definition

<jamesn> https://github.com/w3c/aria/pull/866

jamesn: Essentially removing 1 row for the table
... Its already in the fallback table
... I don't believe this requires any work in core-aam, right joanie?

joanie: right

mck: The way we word things in practices where we don't use any normative language and we use present tense. It basically says that aria-checked attribute is present
... If its checked, value is true, otherwise false...seems to be consistent

<jamesn> https://github.com/w3c/aria/pull/865

jamesn: this is identical as it just removes 1 row from table

mck: I'll +1 this too
... this is primarily for validators

Review switch role: removes default value of aria-checked from role definition

Discussion: Path forward on generic role

jamesn: What is our next step with this? Joanie, any thoughts?

joanie: the attribute needed for the text separator, right?

jamesn: Yes, but I still think we have to resolve the problems with generic

mck: my status - the issue is whether aria {label/labelledby} should be global...
... I think we need to resolve that before we can finalize generic
... I'm a bit concerned that there were some ancillary issues...People were talking about aria-label on a span
... which I don't agree with
... I don't think aria wants to support this on a generic element

jamesn: When are you going to finish reviewing aria-label stuff

mck: we don't need to resolve that to move forward on aria-textseparation
... I'll need 2 weeks
... actually, i want to finish practices (by 17th). So I'd like to commit to being on-top of this issue by the meeting on the 24th
... 17th might be a stretch, we'll see
... I think we should add textseparation to next agenda

jamesn: I agree - we can make generic depend on the labelling discussion. I guess we have a path forward
... we'll work something out to make it reviewable
... Anyone have anything else? I'm sick and could appreciate a short meeting today

mck: +1

+1

- zakim, bye

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/01/03 18:41:11 $

Scribe.perl diagnostic output

[Delete this section before finalizing the 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)

Default Present: janina, jamesn, MichaelC, HarrisSchneiderman, Joanmarie_Diggs, melanierichards
Present: janina jamesn MichaelC HarrisSchneiderman Joanmarie_Diggs melanierichards
Found Scribe: HarrisSchneiderman
Inferring ScribeNick: HarrisSchneiderman
Found Date: 03 Jan 2019
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]