<scribe> scribe: melanierichards
jamesn: gathering agenda items, please put them in the issue, along with how much time you think it'll take, time constraints, people you need to have in the conversation
mattk: I have a topic where I'm not sure about time and know it will take some coordination/preparation. ARIA in HTML specification and how restrictive it is. this issue won't be productive if we're not well prepared
jamesn: perfect item to put in
this issue, you can put in who you think we should coordinate
with as well
... happy to take the lead on coordination once the item is in
the agenda
... please put anything you'd like to discuss in the agenda,
don't worry too much about exact time details
<janina> Will be present Thursday only
jamesn: no updates yet, still on management to send out comms
[marking issues as ARIA 1.2]
jamesn: no AccName issues
... no Core AAM issues
<jamesn> https://github.com/w3c/aria/issues/699
jamesn: at Toronto F2F, decided we were going to create two generic roles: inline and block, which were mocked up in a PR. However, subsequently James Craig objected to the idea. We are getting general agreement that we perhaps want to go for one generic container role of some sort, with a property as to how different parts of text are chunked together by a screen reader, that are coming from a blob
mattk: there are a couple fundamental issues worth highlighting that have nothing to do with language. 1) has to do with inheritance. I'm objecting to this property being inherited by other elements. the type of semantics we're talking about, associated with div and span, aren't strictly related to text nodes, and there could be another widget etc inside a p or span that could interrupt things. if we introduced a concept of inheritance, it would make
the ARIA spec super complicated, and way beyond the scope of role parity
mattk: trying to clear up the fact that it's a mystery to authors as to when style takes precedence (which is applied unevenly between platforms/AT)
jamesn: the inheritance model we
have seems to be breaking things / making them more
complex
... I don't want to just unabstract things, that may have
consequences that we don't intend
... add a new role seems a safer way to do it
... please put name suggestions into the issue
... I don't like blob
mattk: was looking for something
with a connotation of a generic container, but "generic" as a
name connotes only one thing, that it doesn't have a name
... you shouldn't be able to label these
... I've long thought that we should not have people labelling
spans and divs without a role that makes it meaningful to give
this a label
... we should avoid block/inline
jamesn: agree that we shouldn't
use something that has another semantic in HTML, ARIA,
etc
... can we call it "container"?
mattk: might not be a bad idea, worth proposing
<jamesn> Mappings for div and span
<jamesn> span maps to role="blob" with aria-textseparation="inline"
<jamesn> div maps to role="blob" with aria-textseparation="block"
<jamesn> This part....
<jamesn> the above is the part of the proposal in question
melanierichards: I don't think we
should change intrinsic mapping for how child nodes get
concatenated (or not) within div and span, a la the aria
property proposal
... think that could have a lot of unintended side effects
jamesn: [agrees]
mattk: what's uncertain is whose
style-based calculations for this are most correct
... would like to know from SRs how their code works here
... if there is not an implicit value for the property on the
div/span, and they just get the role, are people going to
change how content is processed today?
melanierichards: feels that all the power is in the aria property, not the role
jamesn/mattk: need to map into some role or another for span and div
melanierichards: but aren't they already mapped into group?
mattk: I think group has some separation semantics already built into it, partly by virtue of the fact that it can be labelled. this role needs to be a type of container that I would describe as "seamless". The separation it has with neighboring elements is strictly determined by its contents, not by the container
jamesn: div and span would map into this role, usual styling calculation used, nothing intrinsically changed. and a separate attribute for the user to be able to override the browser. any objections to that? allowed values might need to be flushed out separately
carmacleod: can come up with a pull request just for the role. I can call it container, what would be the superclass?
jamesn/mattk: structure
carmacleod: at this point I wouldn't tackle the attribute yet
jamesn: I think fair to split into two PRs in order to make progress
mattk: ok to do that, although hard to approve of the container role without the property. the role would be the only supported role on the property.
jamesn: we could always add the
supported role into the PR later
... PRs great for analyzing changes
mattk: at some point we need to
say how this container is different from other grouping
elements
... "a generic, nameless grouping element"
jamesn: let's continue discussion on Carolyn's PR
jamesn: moving 322 to ARIA 1.4
https://github.com/w3c/aria/issues/322
https://github.com/w3c/aria/issues/425
jamesn: happy to leave on 1.2 to keep on our radar, but think it needs to be taken up by this math on the web group
janina: think this should be on
that agenda for TPAC
... Monday at 11am at the APA room
mattk: can you add to agenda?
janina: yes, I'll make sure that's part of it
https://github.com/w3c/aria/issues/427
jamesn: I think we should leave in 1.2 despite objection, I'm going to assign to myself
https://github.com/w3c/aria/issues/433
jamesn: seems like this has been resolved. anyone disagree?
mattk: issue is that if you go to checkbox/radio role in the spec, aria-required is not listed as a supported attribute
jamesn: I don't understand the concept of a required checkbox
mattk: HTML supports it
jamesn: why should ARIA support it?
carmacleod: we support it on radio group
mattk: is this something we should take up with HTML?
jamesn: don't think they'll
change it
... you can't mark several radios all as required, that doesn't
make sense
... most people think that if you have a required checkbox, you
must check it to move along
mattk: famous consent agreement
jamesn: it's not that the
checkbox is required, it's that the checkbox value is
required
... I disagree with making a change here, but what do other
people think?
mattk: if someone has a checkbox and for some reason they're not using HTML, and they can't mark it required as in HTML
curtbellew: the case here is really "mark this checkbox to say yes I agree"
jamesn: if we do this, do we add
required value for switch? where do we stop?
... who think this is a 1.2 issue?
mattk: seems like it would fit in well in 1.3 with attribute parity
jamesn: moved to 1.3
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) Present: MichaelC jemma Stefan jamesn janina melanierichards carmacleod MarkMcCarthy hhillen Irfan_Ali curtbellew Matt King Bryan Garaventa Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Date: 30 Aug 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]