<pkra> \o/
<aaronlev> jamesn: I'm lurking on IRC in case bigbluehat is around to plan annotations meeting
<scribe> scribe: MarkMcCarthy
<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-02-07+
jamesn: 4 new issues, we probably
triaged most already
... 901 put in 1.2 bucket
joanie: not at this meeting, but I threw out an option that we can discuss on the issue. I'd like some feedback if we want to limit caption in the case of table
jamesn: let's try to put on agenda for next week
joanie: awesome
<joanie> https://github.com/w3c/aria/issues/901
jamesn: change W3C editorial
version to whatWG
... HTML validator no longer reflects W3C version, all W3C code
removed from validator. suggests we want to point to other
version
... comments? 1.2 bucket?
carmcleod: why did they take that out?
jamesn: I don't really know the
story behind it
... I only know hearsay
carmacleod: okay
<pkra> This might be relevant: https://www.w3.org/blog/2019/02/w3c-strategic-highlights-strengthening-the-core-of-the-web-html/
jamesn: we can reference W3C living standards, so there's no restriction there
carmacleod: I wonder if... if the W3C is publishing snapshots, it makes sense to reference.
jamesn: I've just logged an
issue, I don't think we need to solve it now, just before we
publish 1.2
... just so we don't forget it. so 1.2 bucket?
carmacleod: okay
jamesn: I'll add that it needs
discussion before implementing
... address issue 899 later today
... issue 888 can go in 1.2 bucket.
... melanierichards is taking care of that
melanierichards: whenever we end up doing attribute parity, if it's 1.2 or 1.3...
jamesn: right! it's 1.3.
... no new issues with ACCNAME or COREAAM
jamesn: MichaelC has set up a meeting page
<jamesn> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2019
jamesn: with more details.
confirmed April 30-May 2, in SF hosted by LevelAccess
... topic is to nail down as much role parity as possible.
joanie: quick question: is SF airport the closer one?
jamesn: SF airport is easiest, but Oakland has BART as well. Uber is better with SF
<jamesn> https://github.com/w3c/aria/issues/877
jamesn: joanie, do you want to put up some details?
<jamesn> github: https://github.com/w3c/aria/issues/877
<jamesn> github: https://github.com/w3c/aria/issues/877
joanie: sup and sup were
originally identified as needing their own roles, leaning
towards that
... mck suggested maybe we could use the generic role
... what I put, before carmacleod commented, are thoughts on
why we want a role, in particular if there's semantic
meaning
<joanie> These elements must be used only to mark up typographical conventions with specific meanings, not for typographical presentation for presentation’s sake. For example, it would be inappropriate for the `sub` and `sup` elements to be used in the name of the LaTeX document preparation system. In general, authors should use these elements only if the _absence_ of those elements would change the meaning of the
<joanie> content.
<pkra> pfffft
carmacleod: Sure. It'd be
interesting to have an attribute on that new role as well, as
you've opened the other bug.
... I was thinking if we put it as a generic, there's an option
to have another attribute as well as context
... I called it aria-typography, but that's completely a draft
name
... reason being, the other genric roles we've talked about,
all those almost fit in the same area. I just want to look at
the bigger picture first
... these are sort of the same idea? if we throw thwem all into
the same attribute that specifies "presentational semantics"
maybe that's good enough?
joanie: I raised the point I did
since I am a screen reader developer
... and the generic role might be everywhere. for sup/sup, we
might want to announce them differently than the others
... what carmacleod is describing is essentially asking to
check every generic role for what it's content is
... what might be funny with mapping is that the way it might
be exposed might be different
... aria-typography might be better for something like CSS
carmacleod: I didn't know your platform has it in the API
<Zakim> joanie, you wanted to disagree
mck: as long as I can remember,
we've had this discussion role vs. property
... there's a whole lot of HTML that by default does some
styling to communicate a semantic, like bold vs. strong,
headings, etc.
... these individual decisions about aria-attribute vs. role
seems like a discussion where we don't have many principles,
except what joanie mentioned about platforms
... we don't have consistency across the board with
accessibility APIs
... if anyone can come to the table with cohesive principles,
that'd be hepful. I don't see it.
pkra: the spec description for
sup/sup seems weird. wisest choice might be to say do what HTML
does
... doesn't seem wise to go beyond what they're giving, esp as
this is parity
<Zakim> joanie, you wanted to say the principle is that if an AT can ignore it and the user experience doesn't change, it's generic
joanie: if an AT can ignore and
UX doesn't change, it's generic
... user needs to know about headings, for instance. for
sup/sup, X2 vs X sub 2 or X sup 2 is different
mck: if reading a text, and you
say "all boldface text means XYZ," then there's meaning with
bold text that screen readers don't know
... reader may want to choose to have bold read
differently
... could argue this is true about headings as well
<joanie> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong
<Zakim> joanie, you wanted to say strong versus bold elements
mck: we might want to mimic HTML, which might not be best but defendable
joanie: I hear you mck, but HTML
for better or worse has bold and strong. sometimes authors need
guidance
... authors should use b tag if it's not semantically
important, strong if it is
... so I'd like b to be generic, ideally, and strong not
generic, so screen readers present items differently
mck: do DPUB folks have something to say?
jamesn: no one here today
pkra: I don't know why use case isn't mentioned, but there's obvious use of subscript, like chemistry etc.
jamesn: we'll have annotations
pkra: though I suppose you find footnote -scripts in MathML too
jamesn: are we near a conclusion? many opinions. I'm leaning towards that if it's on a platform API then go for it
carmacleod: +1
joanie: yes, but not all APIs have the same things
jamesn: it should be an indicator to us that if it's in a platform API and we decide it's not semantic, that'd be a mistake
mck: what we don't tell screen reader devs is that you always announce roles and sometimes properties - that's not our job
joanie: right, i didn't say
that
... concensus is what?
jamesn: expose as roles?
carmacleod: yes, i'm okay with that. I can see the screen readers POV now
<pkra> +1 for roles
mck: maybe for the generic case, it's generally the browser's responsibility to take care of element attributes?
jamesn: let's talk about that when we come back to generic
mck: let's go forward with roles
[no disagreements]
JamesCraig: thanks for discussing generic, it's important to me
jamesn: this is jongund's PR, there's been some updates
<jamesn> github: https://github.com/w3c/aria/issues/867
jongund: updates are that I added the roles we discussed, I'll add a link to changes
jamesn: 867 is the wrong issue, oops!
<jongund> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#label
jongund: this should be updated code. I went through roles related to encapsulation based on HTML5
<jamesn> github: https://github.com/w3c/aria/issues/876
jongund: I changed the language a
little bit, but the big issue is defining what the list of
roles would be and how to get an acc name to them
... there's 30-40 different roles, take a look
mck: i still think there needs to
be a way to represent this for tables, something equivalent
like encapsulation
... especially with all the tools that parse our spec
jongund: i agree
... there should be something in the table for roles that can
be labelled through encapsulation
jamesn: this is way more than I expected based on last time
jongund: i thought it'd be a small list too, but then you have to look at the principles and what HTML does
jamesn: things like a document or an alert...
mck: or buttons, maybe there are some things to throw out
jongund: I'm happy to take some things out if necessary
mck: anything that's a structure has to fall out of here
jamesn: some things should have
further discussion, but let's start with a smaller list first
and add more later
... a small list going into production first would be
better
mck: is an aria-button like an input type or element? semantically it's equivalent to both?
carmacleod: yeah, it's weird
jamesn: let's take out button and add it back if we want to
mck: combobox is weird, since it's complex
carmacleod: but it needs a label
jongund: the question here is what makes sense from an authoring standpoint
<carmacleod> List of labelable elements in html: http://w3c.github.io/html/sec-forms.html#labelable-element
jongund: one of the things this
does is let people have a visible label. so it's probably more
useful for combobox than checkbox
... I don't have to worry about IDs, or aria-labels or
-labelledby
jamesn: I'm happy to hear either
way on combobox
... let's go through a smaller list next week?
JamesCraig: I think it's fine for any form control, but if we decide to keep structures it's possible to have some implementer impact
jamesn: that sounds like a good comment. I'd like to limit to form elements and add other useful things later
<CurtBellew> I'd like to understand why "list" wouldn't be on this list
jongund: i'll whittle down the list and we can discuss next week
CurtBellew: I can wait til next week. I've had a question on that for a while but happy to wait
JamesCraig: one more thing, where
would encapsulation stop?
... that's something we need to consider
... i.e. can i walk up the ancsestor chain, do i encounter
anything that'd conflict?
jongund: that'd be in ACCNAME I
think
... but you're right, that has to be defined
jamesn: this is what JamesCraig wanted to discuss
<jamesn> github: https://github.com/w3c/aria/issues/899
JamesCraig: basically, on a news
site, every article kept saying "article" even though
everything looked right
... so maybe we need more flexibility for inferred labels
... in particular <dialog> and <article>
... might not want to pick the first line, but if there's a
first (unique) heading, that could be inferred
... in <dialog>, it might be useful to be even more
flexible. if there's a logical first line of text, we could
infer it's the label
jamesn: joanie is very against
any heuristic fallback, so if we can define and glean general
support, that's fine. but we have to define correctly
... need definitive guidance. gut feel is that it'd be the
first child heading
... might not work with everything, but as a screen reader dev.
you're free to do as you wish
mck: it seems to me like that's
too loose, because if you have a bunch of descendants, that
might not be a good heuristic
... i don't know how you'd limit it
... inference is tricky and kinda risky
... risk of having wrong label on these... for a dialog not
huge, but for article could be a lot
JamesCraig: I think this would be lower in priority than title. only if there was no label conveyed would this apply
Stefan: I'm in Joanie's camp,
this could have lots of implementations and could be
complex
... some screen readers may behave, some may not
... it's a good idea, but it might often get corrupted
jamesn: i propose that someone who's interest, collect data on what might work for articles etc. and determine if we can come up with a programmatic, 90% correct idea
mck: I don't know if I'd support
that, it's too easy to collect potentially junk data
... I'm agreeing, if its an absolute fallback esp. if the
experience isn't optimlly coded
... some people accuse Vispero for not waiting on data, others
accusing NVDA of the opposite - there's lots of
perspectives
... idea that we're building in inference is an interesting
proposal
... we should do so cautiously. data might not help
JamesCraig: the context is
prioritizing needs of users over all
... if specification is too rigid, it can be challenging to
make things work for users
... similar to this is browsers and layout vs. data
tables
... even if something doesn't work, i might need to do
something anyway. I wanted to, if possible, find a great
solution for user agents and users even if spec and authors are
wonky
Bryan: i agree, but I am
concerned about if we open the door to this, we might see more
bad coding practices
... if you go to devs and ask "do you want to label things or
have it done automatically?" obviously they'd say yes
... we don't want to promote bad practices
mck: +1 to spirit of JamesCraig's
intention
... ideally, we want to prevent the automatic thing
<pkra> bye
jamesn: this was a great discussion. JamesC, it sounds like you need articles to have an ACCNAME?
JamesCraig: I don't know if I'd
use require, but if we land on it with no label, we just read
role description
... particularly with the VO rotor
... i'm trying to make that UX better
jamesn: could you read the first line if nothing defined?
JamesCraig: we'd have to look
into things a little more
... there is a risk of weird worseness, but if 90% is better,
that's a win
jamesn: and author can override with a label
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) Succeeded: s/mroe/more/ Succeeded: s/impcat/impact/ Present: Stefan Joanmarie_Diggs jamesn pkra MarkMcCarthy janina melanierichards CurtBellew jongund MichaelC Found Scribe: MarkMcCarthy Inferring ScribeNick: MarkMcCarthy Found Date: 14 Feb 2019 People with action items: 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]