Meeting minutes
First import of PDF-AAM mappings https://github.com/w3c/aria/pull/2466/
Zakk: Thanks for your commits Daniel
… I mentioned a couple of lines we could look at
<Zakk> lines: 264, 278, 361, and the table starting on 396
Line 400 -- label role
Zakk: We wanted to try this one out as there is not a clear correspondence
… We may need to create a new pDF row
… How could we provide guidance?
JamesC: In this case you would point to the HTML-AAM, you could just say "use the HTML mappings"
Daniel: See my comment
Daniel: That's how this should look like
JamesC: You don't need to map a pdf- role. If you did, we should probably decide if we need to put it somewhere in the dpub-aria
… HTML has one and I am not sure if it predates this
Duff: I was reading a GitHub discussion about this. But we should cover other use cases of the `lbl` element that don't have a good paralel on the HTML element
Paul: We have both of them taken into account
JamesC: In HTML you have `a` element with and without and `href`. That could be the approach
<jcraig> https://
Zakk: I just need to change this
Zakk: What do we want to put on line 412 for the non-HTML elements?
JamesC: in this case it would be `<code>label</code> element`
… For the others, use HTML-AAM mappings
JamesC: We sshould probably leave the note
JamesC: If no link, we should probably remove the class
Duff: We have use WAI ARIA mappings. Should we use PDF mappings?
JamesC: "In the context of forms" is a bit tricky. We should be more explicit. I think in HTML it calls out the relationship
… Is there something that the PDF author should take into account
Zakk: Label as a child of a form element?
Duff: You have to give the correct semantics for it
JamesC: Child of, group with, or maybe a tagging relationship. Maybe in this case the parenthetical can be replaced with "label which is associated with a form element"
Paul: that makes sense and plays well with the other ccontexts where lbl is used outside forms
Zakk: This is role label forms, and the other can be role label list
Paul: Label can be used for headings as well, not just lists
Zakk: Yes, I was just thinking from an organizational perspective, we can get as specific or as general as we like
JamesC: Anything that requires a different mapping needs to be called out separately: form elements, lists, headings, and maybe a catch all
Duff: There are three: forms, lists, and content. Content could be headings, footnotes, etc
Zakk: There is also the generic which maps to generic
JamesC: I think you want to add the parenthetical outside the `code` block: "label other than in the context of lists of forms"
Paul: We haven't broken out labels that match
Zakks: List numbering or the other various ones we are going to have to provide guidance for some of the unique labeling.
Paul: If they are going to be generic do we need to separate them out?
Zakk: No. We only need an additional mapping if the platform mapping is different
Paul: So I would say forms and out of forms for now
Duff: Don't we want to clarify that there is additional consideration for labels that may not map to generic?
JamesC: We could include it in a note
Zakk: Ideally is to have these eleven entries ready for the Editor's Draft
Duff: It's in scope and may create misunderstandings if not addressed appropriately
Daniel: I think priority for us is to have the import script working. We could clarify the situation on the status of this document so that it's clear upfront for everybody
Wrap up
Zakk: Let me know what we need to do to get this merged
Daniel: I'll re-review these last additions, then ask Valerie for review and if she's happy we can merge