<matt> Test
<matt> test2
<matt> hello?
<scribe> scribe: melanierichards
jamesn: need more agenda items,
please
... would like anything that anybody wants on the agenda,
please put it on this issue
Stefan: I have various items to add to the issue in Github. clarification around use cases involving list items, extensions to grid role, etc
jamesn: especially want agenda items that involve other groups ASAP because other groups have fuller agendas
jamesn: we have our charter
extension sent out, extended til end of October
... we can publish again before that extension expires. we
should publish if we can, because we're not guaranteed another
extension
joanie: working on fixing UA bugs in AccName
jamesn: there's a moratorium around publishing near TPAC
MichaelC: [shares some dates]
jamesn: so we could publish right after TPAC but before the charter expires
<jamesn> https://github.com/w3c/aria/issues/812
jamesn: this is already in 1.2 milestone, self-assigned to Matt. anyone think this isn't a 1.2 issue?
mattk: I submitted a PR, too
jamesn: haven't had time to review, and it's not on this week's agenda. is it quick enough to go through now?
mattk: people should probably look at it, it needs wide review
jamesn: seems related to the next
issue
... including in 1.2
<jamesn> https://github.com/w3c/aria/wiki/Required-Properties-with-Default-Values
<jamesn> Issue 787
<mck> /me Yay, have an IRC solution working with NVDA now
jamesn: carolyn's taken a first
stab at cataloging required properties with default
values
... one thing I wasn't sure about was spinbutton valuenow,
whether that really should be required. I think that's related
to Matt's issue. maybe remove these from this table and point
to another issue
JF: I'm looking at the table, wondering why the default heading is default to level 2 and not level 1
jamesn: no idea, it's a
historical thing. If anyone knows why, please speak up
... the whole question is if something is required, why would
it have a default value? what does that mean?
... anyone know why we chose heading level 2?
mck: adding a bunch of heading level 1s to a page, we felt would be a really bad idea. And there wasn't any logic to going deeper
JF: if I encountered a page with multiple level heading 1s, I agree it would be a lousy experience, but I would know right away that there was an author issue
<Zakim> JF, you wanted to ask why the default heading is level 2
mck: on most pages, there's probably going to be other headings there. If we make no assumption of whether or not other headings are present, you've done less damage by assuming a level 2. Whereas if none other are present, you've done no damage by assuming level 2
JF: thank you for putting more clarity on that
<JF> +1
jamesn: for this one, we're
keeping it as a required property, removing the default and
putting it into a "user agent repair technique"
... does anything jump out in this table?
mattk: in this table, these are all the ones that have required values and default?
jamesn: correct
mattk: are you asking do we want to make the same decision for all of these?
jamesn: no, line by each one.
either the property stays as required or it is moved to
supported. and if it's required we can take the default value
out and put it in the fallback table
... if anyone has any comments, maybe edit the wiki and add
your notes in the notes column?
mattk: do you want the comments in the issue?
jamesn: ok with either
... might be easier in the wiki notes to separate them
out
... having in the table will make it easier in my opinion to
reconcile the properties
carmacleod: curious why you don't want the defaults in [missed]?
joanmarie: to me, AAM is platform specific. if an author doesn't put the required value, that has nothing to do with accessibility APIs and thus AAMs. Think we should have a new section in ARIA spec about handling author errors
joanie: I will write this as a meta-comment on the wiki
mck: I agree with Joanie's logic.
I'm not sure I agree with the idea that there shouldn't be any
default values provided. If we're not going to change that, we
should change the definition of a required property in
whichever section that is defined
... I would rather say the result is always undefined
... and that can be part of the definition of a required
property
... there isn't really meaning in being required if there's a
default value
jamesn: not really, because a validator can flag it as a conformance error
mck: if we want that to be the only difference, we should change the definition of a required property
jamesn: what's your objection to a separate "error correction strategy" section?
mck: I'm not necessarily opposed.
I would require that it not be something buried
... we should mention that UAs have implemented a fallback, and
then we can link to that fallback
<jamesn> https://www.w3.org/TR/core-aam-1.2/#document-handling_author-errors
jamesn: Core AAM already has a
handling author errors section
... this whole thing isn't a mapping thing, I'm thinking Joanie
is looking at this all not being in AAM
joanie: yeah
mck: not all specs specify how to handle author errors. [cites HTML]
jamesn: it does a relatively good
job now, I think it used to not
... FF in particular does not want to do much validation on
things. these are not requirements, most of them are not
MUSTS
or MUST NOTS
jamesn: please review and put comments
Harrisius: I can put a comment in
GH about scrollbar value
... I feel like the default value would make more sense being
the equivalent to aria-valuemin
carmacleod: I think I agree
<Zakim> Harrisius, you wanted to ask why the default aria-valuenow is halfway between valuemax and valuemin
jamesn: Carolyn did a first draft of our new container role (issue #699).
carolyn: I found a lot of the
word "container" in the spec. If we call the role "container",
that's going to cause a lot of confusion. I went back to the
word "generic" for the role. We can still discuss, this is just
for the sake of getting words in
... a container element that has no special meaning on its own,
but it represents its children and can be styled
<JF> is there a related URL for this?
carolyn: HTML <div> and <span>
https://github.com/w3c/aria/pull/805
https://github.com/w3c/aria/issues/699
carolyn: I think we want the
default value for this attribute to follow the style, the
visual rendering
... sometimes things are read differently than they look
jamesn: div with different presentations is read differently in different UAs, authors should be able to override
carmacleod: I think those are bugs
jamesn: we shouldn't break what UAs are doing with ARIA
carmacleod: we might be saying the same thing and I'm misunderstanding
mattk: right now there's a ton of
divs out there that may have an inline look, but they have some
spacial separation. and if screen readers were to treat them as
if they were spans, then those spacial separations would
disappear and things would get chunked together and make the
content unreadable
... I think that would happen more often than the other way
around
... we already have some content out there that is broken up in
a divvy or blocky way, that would be good to read as one chunk
but with spaces. and so authors can override to get that
behavior
joanie: it's valid that we don't want to mess anything up. What about divs that don't have any roles/properties on it? We can divvy this up as separate problems
mattk: you should never apply
this role to a div or a span, because it would be like putting
a heading role on an h tag
... this role is for mapping only
jamesn: what about "generic" is the role, with aria-whitespace as a property with various values (james's proposal)
mattk: I don't like "whitespace" because it implies it will only handle whitespace. would rather have "text separation"
jamesn: do we have agreement to
stick with generic and add a text separation property with
"inherit" as the default?
... generic container seems...clunky?
mattk: all other roles I see in
the spec are nouns, and this is an adjective. so it doesn't
work as a role for me
... I do think the description should say this thing is
nameless
jamesn: should we add somethiing for accessible name not allowed?
mattk: we currently have accessible name required can be true or false
jamesn: could be required,
allowed, or not allowed
... maybe we need an issue for that
... my proposal is we for now go with generic, but we can
change it. any objections?
[silence]
jamesn: my other proposal is we add an attribute aria-textseparation
<jamesn> https://github.com/w3c/aria/issues/699#issuecomment-416096296
jamesn: with those values
... objection as first draft of those?
[none]
jamesn: would you mind adding the attribute?
carmacleod: will do!
scribe notes, "mattk" and "mck" are the same person :)
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/hem/them/ Present: jamesn jemma Joanmarie_Diggs melanierichards JF MarkMcCarthy Harrisius Stefan hhillen curtbellew MichaelC jongund carmacleod Bryan_Garaventa matt_king Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Date: 06 Sep 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]