<scribe> scribe: melanierichards
MichaelC: AccName I've sent the transition request (to CR), targeting publishing next Thursday. No info on when it'll be processed. In progress of working on request for Graphics ARIA and AAM. Hopefully today
joanie: I was at a American
Institute Mathematics workshop focused on accessibility. Lots
of representation: I was there, NVDA, Chrome Vox, publishers,
professors, college and university offices for assistive tech,
MathJax folks...we started tackling problems like MathML isn't
necessarily a valid solution for everyone, but when it's there
we need to make it accessible. How does ARIA play into this,
Braille, etc.
... now the question is, how are we going to work on these
ideas?
... let's have ongoing communication between the groups (w/
"Getting Math on Web Pages" community group). another
possibility is some math deliverables.
<MichaelC> https://www.w3.org/community/mathonwebpages/
<joanie> https://www.w3.org/community/mathonwebpages/
<jamesn> or even better https://w3c.github.io/mathonwebpages/
joanie: I left the community group meeting and they used to have an a11y task force, and they plan to restart it. One of the questions is, do we want to do a joint task for?
for => force
joanie: I would like to be a
member of that task force. Also had the idea of one of the
workshop attendees being invited to ARIA WG as an invited
expert
... we would like to have more accessible SVG for mathematical
expressions
jongund: do you have to be a W3C member to be part of the community group?
joanie: you do not
jongund: may have a contact to potentially invite to the community group
MattKing: would like to have members of the ARIA authoring practices task force participate in this
jamesn: kind of feel the same way as Matt
MichaelC: I agree that a task force that has no participation doesn't do much, if people join the group in order to work on the task force, that helps. but we're not ready to make a decision on a task force in the first place. not sure of what stage of maturity the work is in. let's establish channels of communication with the community group (already happening with Joanie). I could see forming a formal task force when the work is on the REC track
joanie: if it's a joint task force between a working group and community group, people can join the task force without joining the working group?
MichaelC: don't think there's necessarily a structure in place, but can work with it, primarily a shared mailing list and a Github repo. Can operate that way without creating a task force
<bgaraventa1979> I've been on the call, I support joint cooperation, but my time is extremely limited personally so I can't commit to more projects
jamesn: essentially treating the community group as an incubation place, would have to move to working group to be formalized?
MichaelC: yes, and the work could go to this working group or a new one
joanie: we wouldn't create a formal task force between a community group and a working group because there's not a formal structure in place, we want to establish communication channels of some sort and liason heavily, and then when we're closer to have mature deliverables, we'd have to have a conversation about who owns it. Possibilities are the ARIA working group, another working group, or the community group could spawn a working group
Janina: the look of something that's MathML based is very important, it's important that gets followed up on and there's an accessibility aspect to that as well
MichaelC: targeting the week of June 18th for making the decision.
jamesn: July 25th is the deadline for publication before moratorium
MichaelC: for FWPD could send it on July 16th
<jamesn> https://github.com/w3c/aria-practices/issues/700
jamesn: waiting on the ARIA authoring practices in order to get this work done. 2 issues that we need to work out how to resolve
<jamesn> https://github.com/w3c/aria-practices/issues/701
jamesn: issue 700 is about putting in something about blockquote, caption, and paragraph roles
MattKing: since they're
structural, an example doesn't have to be much more than the
examples we put in the ARIA spec, static text.
... if you're going to say not to use something, there has to
be some kind of rationale behind that. I don't have one,
really.
... there are bunch of structural roles that fall in the same
category already, heading is one of them. We don't need a lot
of guidance here, tempted to have a couple paragraphs about
legitimate/recommend uses of these are. One of these is
repairing content, where using the native element would have
undesired side effects.
... would like someone to help author, the uses related to web
components in the shadow DOM, we'd like to reflect these in the
shadow DOM but don't have the native element
jamesn: we can reach out on that help if no one volunteers
MattKing: we have these two paragraphs, and a list of the roles that fall into this bucket, which includes the new ones. We can hopefully offer a couple examples. At some point we'll have to compare these with the ones that are done as properties, which will get added to the same section
jamesn: we have a plan on how to
do this content, we can discuss in the APG call
... 701 is the other blocker, about IDL.
MattKing: I'm comfortable with this being the simplest form of something that replicates what's in the ARIA spec. will need to add a few words about why we have it
jamesn: I'll do the example, we should be able to get done quickly
joanie: do we need ARIA tests for IDL reflection? will this be testable via automated testing?
MattKing: you need to be able to
test that the browser did what it was supposed to do in
response to the JavaScript. normally you'd take some static
HTML for your test case, but in this case you'd have to run the
JS as part of the test case to verify the must statement.
... definitely testable
joanie: in terms of the workflow
in case of reflection, we're also blocked on writing the test
cases
... for structural roles, we already have test cases and
passing implementations
<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#in-progress
<joanie> https://w3c.github.io/test-results/core-aam-1.2/all.html
joanie: in that link, everything
is passing. except one remaining issue with caption in
Gecko
... can get a fix out for that
... once blockquote role lands in IA2, will update mapping for
IA2
... because of our workflow, we were able to catch early in a
web platform where the implementers were like, "we should add a
new role for this". I think we're going to catch a lot of this
stuff a lot sooner.
<jongund> Great work joanie
<jamesn> https://github.com/w3c/aria/issues/773
<jamesn> Value representing true or false, with an intermediate "mixed" value. Default value is "false" unless otherwise specified.
jamesn: about the definition of tristate. We state in our spec that it's false unless otherwise specified. We have two different tristate properties, which have a default value of undefined. This PR changes the statement so that it is undefined unless otherwise specified
joanie: in favor of change
MattKing: this came up before in 1.1, we were going to CR. big discussion came up in defaults and what "undefined" means. this change is an example of a step in the right direction. Less damaging for UAs to use undefined if they don't have one of these other values
joanie: changing the default doesn't have anything to do with Core-AAM
jamesn: anything else we need to do other than accept?
joanie: yes we need to do something, but we should accept it. what I would suggest we do is: all normative changes that potentially, likely, should have a test case, should have a changelog entry.
jamesn: I'm not sure there is a normative change here, both referenced properties have "undefined" defaults, which override this statement anyway
joanie: simple changes we should still determine if a test is needed, and if so, do it. And a way we can figure it out is by looking at the changelog. If you're the one that merges it, please add a changelog entry.
jamesn: will merge and add changelog entry
jamesn: we looked at this
previously, where Matt K. made some suggestions, have a change
based on those suggestions.
... "A widget that allows the user to select one or more items
from a hierarchically organized collection." is the new first
sentence
MattKing: still likes this language
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/pull/766.html#tree
jamesn: I propose we merge and
close it
... Objections?
[no objections, will be merged]
<jamesn> https://github.com/w3c/aria/issues?utf8=✓&q=is%3Aissue+is%3Aopen+created%3A%3E2018-05-15
<jamesn> https://github.com/w3c/aria/issues/780
jamesn: would like to discuss new
issues in calls so we don't have a buildup. would like to talk
about the first one in more detail (#780)
... [reads original message on issue] I did a PR to change
that, and joanie had some thoughts about why not to require
it
joanie: as an aside, earlier Matt
mentioned that undefined seemed safer than a UA taking a guess
that might be wrong. My thought is to have it be required, but
default to undefined
... really don't like the idea of this not becoming a
not-required property, because this information would be really
helpful to AT and users
<joanie> https://www.w3.org/TR/wai-aria-1.1/#state_property_processing:
<joanie> WAI-ARIA roles have associated states and properties that are qualified as "supported" or "required". An example of a property supported by the combobox role is aria-autocomplete. The property is designated "supported" in this case because a given combobox might or might not implement auto completion. In contrast, the combobox role requires the aria-expanded state in order to indicate that it is expandable.
<joanie> Comboboxes have a descendant listbox that is either open or closed. If the listbox is open, the combobox is in its expanded state; otherwise it is collapsed.
<joanie> [...]
<joanie> However, required states and properties that are absent are an author error. Missing required states and properties are treated as if they were present and have an implicit neutral value that is not necessarily their default value.
joanie: I think this applies here, and we should keep it required instead of just having it supportive
MattKing: wonders if this text reflects reality and if we should change the text
joanie: [thinks perhaps]
... the prose has an issue, but there is code in Webkit where
"if this property is absent, what should be here"
<jamesn> https://w3c.github.io/aria/#scrollbar
jamesn: we have min/max/valuenow: how do you get values if they're missing? we can do the same with scrollbar, a repair technique
joanie: in favor of the authors must be added, still in favor of keep it required, may want to change implicit value
<jamesn> In ARIA 1.1, the default value for aria-orientation changed from horizontal to undefined. Implicit defaults are defined on some roles (e.g., slider defaults to horizontal; scrollbar defaults to vertical) but remain undefined on roles where an expected default orientation is ambiguous (e.g., radiogroup).
jamesn: if we do change anything, then we have to change or remove this text as well
joanie: I borderline cannot live without it being required
jamesn: [raises compat concerns]
[group doesn't think we can resolve today]
MattKing to come up with some examples
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/July 18th/June 18th/ Present: Joanmarie_Diggs MattKing MichaelC melanierichards jongund janina Bryan_Garaventa Regrets: IrfanAli Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Date: 07 Jun 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]