<janina> I will need to leave about a quarter of
<scribe> scribe: HarrisSchneiderman
MichaelC: official charter out hopefully soon
<janina> e-champaigne soon!
<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2018-10-11+
jamesn: anyone not agree with 826 in 1.2?
Investigate if we need to add URL to validator #831
When there are role errors where HTML in ARIA says certain roles are not allowed on HTML elements, need to investigate if we want to add a URL such that we can give extra information about the error
jamesn: where does this fit in our milestones? anyone have any vote?
joanie: how about 1.2 for now?
jamesn: I agree - we'll put it in
1.2 milestone
... done()
joanie: maybe we should investigate #832 in 1.2...if we can - otherwise it should get pushed back to 1.3
jamesn: I've added help wanted label to issue
jamesn: marked #35 with 1.2
... I've marked the rest with 1.2 as well
... To me, they all sound like they should be addressed in
1.2
<jamesn> https://github.com/w3c/core-aam/issues/28
joanie: #28 - 1.2
... 28 is basically becoming obsolete
... if needed, this would be a new issue in aria
carmacleod: assign it to me if we need a new issue
joanie: in the aria spec there is also content about the a11y tree, we don't know if it has anything about hidden in it
carmacleod: how about I comment on this ticket about moving this
jamesn: any comments on this?
<jamesn> https://github.com/w3c/aria/issues/834
crickets
<jamesn> https://github.com/w3c/aria/issues/833
jamesn: onto issue 833
jamesn: lets go over bg
... so we have new generic roles and other things in which the
thought is - theres no reason to name these container elements
(without any real meaningful role on them)
... generic roles, paragraph roles etc...why would we need
label on these?
... initial proposal - prohibit naming of the roles listed in
ticket
<jamesn> blockquote
<jamesn> caption
<jamesn> listitem
<jamesn> paragraph
<jamesn> presentation (already prohibited)
<jamesn> none (already prohibited)
mck: the problem is - when the screen reader is rendering the element (such a paragraph), the semantics aren't directly revealed (unless navigating by paragraph with AT), in the real world if the paragraph has a label, that label is a heading. AT would have to come up with a whole new paradigm for this (how do you associate a label with a paragraph if your a screen reader). A div w/o role is invisible to a screen reader.
joanie: if you have text that the user might want to read by line/word/char. if the AT speaks the label instead of content. Its confusing if the user can't traverse to text read out as accessible name. User might want to select the text
mck: VO renders labels on
landmark regions
... heres an example of what we want to prevent: with a title
on div, VO thinks this is a group with a label. so it renders
(to VO user) a "start" and "end" of group. If title happens to
be redundant user gets this in triplicate
HarrisSchneiderman: What about just using offscreen text?
mck: thats fine, AT knows how to
render actual text in DOM
... If you label a table via caption - the screen reader tells
you where the beginning and ending of the table is. It's how
you know the bounds of the table.
... If you have a div, you would never render the beginning and
ending of div. That'd be a nightmare - way too verbose for
screen reader users. A div isn't a semantic thing so it doesn't
make sense to render begin/end
jamesn: Carolyn brought up interesting proposal - "So maybe the easiest way to spec "prohibiting author naming certain roles" is to remove aria-label, aria-labelledby and aria-describedby from the list of global attributes, and then list them separately on all of the roles that don't prohibit their use?"
<janina> Need to go--bye, all!
mck: this might be the right way
to approach this - these attributes aren't quite global
... we need to map out the potential side-effects
carmacleod: This is doable and it solves some problems
<joanie> The word "global" appears 3 times in the core-aam.
<joanie> one instance is "globally"
mck: making these non-global would bring some level of relief to developers of screen reader software
carmacleod: this should be a pre-req for the generic role
HarrisSchneiderman: What role / how should you label, a scrollable region?
mck: Does it have to be focusable? does the container have to be focusable?
jamesn: yea for keyboard users
mck: Whatever is inside of that scrollable area, the content within will affect what you choose as the containing element. We don't yet have aria semantics for pre and code. My gut tells me it should be a "code" (role?) element. Screen readers are going to get all of that content at once for free (without scrolling)
jamesn: we have better solutions than a div with a label. We can still cope with it today - even without the code role
mck: group or region could apply
depending on what it is? What about labelling a block
quote/code/pre element?
... Jaws / nvda / VO (maybe) currently notifies user that they
are interacting with block quote. I'm wondering if you should
be able to label these similar to how we label articles
jamesn: I'm hearing that we're all in favor of this
+1
jamesn: we might as well not cover our last item based on above
<Zakim> joanie, you wanted to mention text/caret navigation
<jamesn> https://github.com/w3c/aria/issues/699
carmacleod: in one of the later
comments, someone had a suggestion for me. I had said that for
aria-textseparation, I thought I'd like to have a 2-item token
list for the before/after separation...I've played with that
and its weird (to describe and use)...BUT we still need to
address the before and after space (avoid too many tokens). My
next suggestion is to split it into 2 properties (possible
name: aria-textseparation before/after).
... if one property is not present default to whatever the
style is
... I don't know what the potential misuse of this could be -
we could specify documentation on how to avoid misuse
... is it ok to split this into 2 attributes?
mck: I started playing around
with the 2 token idea. I found 2 token approach really simple
to explain. I think having 2 properties could be quite
messy
... I separately propose that we have a token of "string" and
in subset/separate property specify what the token is
... specifying these things without actual tokens would be
difficule
carmacleod: I thought that these would be ok as non-tokens
jamesn: could we use html entities for this?
html entity for break:
in css we can use \A for line break
carmacleod: what to do if only 1 token?
mck: I was pretty simplistic in my notes to freedom scientific, I can dive deeper
akim, bye
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) Default Present: janina, jamesn, melanierichards, Joanmarie_Diggs, HarrisSchneiderman, carmacleod, Bryan_Garaventa, matt_king Present: janina jamesn melanierichards Joanmarie_Diggs HarrisSchneiderman carmacleod Bryan_Garaventa matt_king Regrets: CurtBellew MarkMcCarthy StefanSchnabel Found Scribe: HarrisSchneiderman Inferring ScribeNick: HarrisSchneiderman WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Nov 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]