<Dorothy> am i always number #4?
<Dorothy> k
<Dorothy> it asks for a code but i do not know what to enter.
<scribe> scribe: Irfan
jn: not tarketing to 1.3. we have 15 PR's need to et as many of them as we can to get merged
<jamesn> https://github.com/w3c/aria/pull/799
mk: some sentimental issues that we can't close on quickly in next few days.
need to talk about it before we close them
if we can check aria-checked or aria-selected
complicated to resolve partly because we cant get all the people together at the same time
jn: reasonable... need to put a
label into in
... need to get back to it soon
mk: need to address it before 1.3 release
jn: I can put it into agenda and we need to address something sooner as soon 1.2 out of the door
<jamesn> https://github.com/w3c/aria/pull/852
jn: Editorial cleanup needed to "Presentational Roles Conflict Resolution" section
mk: havent looked into it. but I should look
<carmacleod> Preview of Presentational Roles Conflict Resolution: https://pr-preview.s3.amazonaws.com/w3c/aria/pull/852.html#conflict_resolution_presentation_none
mk: we do not want to review it in real time in the meeting
jn: I will merge it my end of the week
all my merging will be done by end of this week
if you want time to review this by friday.
https://github.com/w3c/aria/pull/950
carmacleod: Tree Inclusion focus/activedescendant requirements need clarification
<joanie> I think we may wish to rebase or do a new pull request https://github.com/w3c/aria/pull/950/files
carmacleod: The only change is the 2nd bullet in 7.2 Including Elements in the Accessibility Tree - the one with 3 sub-bullets.
mk: even if it is aria-hidden, it should still be in a11y tree
dont know if it is sr or browser.. my understanding is aria-hidden hide it completely
not clear if this is normative info
carmacleod: text node must be in the a11y tree. yeah it is normative
jn: i question if it is right thing. if you have tabindex -1 on a link, it will still have focus
mk: visible and non-hidden is confusing. does visible actually means visible on the screen?
in a11y tree, you could be focusable but not focus. -1 tabindex, you want to make focusable only for screen reader users.
jn: we can get in agreement for 1.2 or we can move it to 1.3
carmacleod: are we happy with the words that we have now?
jd: do i need to write test for this? if yes, that suggests that you are making normative changes.
mk: doesnt mean that it is normative changes. it means that it is more clear that previous normative language
??: what is visible means... visible to a11y tree or view port?
<jamesn> this is the 1.1 version - https://www.w3.org/TR/core-aam-1.1/#include_elements
mk: we are struggling with words here. the definition of the terms matter here.
jn: it didnt get editorial clarity.. thats why we have this issue now. question, is the new version is the same as previous normative version
carmacleod: hidden has clear definition. it is more clear to use non-hidden
jn: if any user can see if it is non-hidden
mk: non-hidden is the right thing.
jd: I wonder if we are making it too hard.
jn: someone using AT might need to interact with this
mk: perceivable.. if object is there, has to be perceivable
jd: it should technically have an accessible object.
<Jemma_> I also think we make things too complicated for readers of the doc. user should go through each definition, ie hidden and figure out the core concept
<Jemma_> and connected that back to the original intention.
mk: just wondering if we are making it too hard. my understand is that if object is in a11y tree
jn: not sure if we are making any progress, if anyone wants to propose anything by end of the week, please do so.. dont have enough time
<carmacleod> Updated: https://raw.githack.com/w3c/aria/car/issue841/index.html#tree_inclusion
jd: quick functional request... even if everyone is reviewing this.. if you look actually diff.. something is not right...
mk: after it goes out for wide review, the only thing that could be merge something that is surely editorial. audience for this one is like 4 people.
jn: dont want to spend time on it now until next version.
mk: the reason I am carrying is because I have experienced some situation because, certain browsers are respecting these normative requirements
jn: it is just clarifying language to making things clearer
<jamesn> https://github.com/w3c/aria/pull/1023
jd: give me a test case.. where is the failure
jn: brian had a concern with 1023, are you okay
bg: yes
jd: I am godo with i
jn: believe user agents must
remove 4 Global States and properties
jd: this could be authoring error..
it would have been lot better if it was not authoring error
mk: it is an important issue. i think we had problems whatever specs are now, we should stick to it
<jamesn> "User agents MUST ignore non-global states and properties used on an element without a role supporting the state or property;"
jd: we would like it to see in 1.2 and need to priortize. need to write tons of tests
jn: we are good to merge into masters and Jonnie have tons of stuff to do
mk: I am going to look into it after the meeting. Please dont merge it right away
jn: https://github.com/w3c/aria/pull/1051
mk: we can't leave this combobox issue open
jn: there is a controlling relationship. using aria-controls is proposed
mk: that what we use for all other places.. tab-menu
structural issue here is very fundamental which is on wiki page. leaving these issues open means more and more issues.. and we need to put a stop to it.
some aria wiki page has details
<joanie> https://github.com/w3c/aria/wiki/Resolving-ARIA-1.1-Combobox-Issues
it is good for people to read this. dont have link for pull request or summarize all details. but I think this is something really need to be fixed
having a meeting with MS this afternoon.
jn: if you need me to join, let me know
bg: i can join as well
mk: if we do not do anything and we put off to 1.3, it is a situation, I would change APG prior to spec being final.
this is going to help with whole HTML select thing
jn: we cannot merge it right now
https://github.com/w3c/aria/pull/1069 ready to go
https://github.com/w3c/aria/pull/1070
this is insufficient to close
<jamesn> https://github.com/w3c/aria/pull/1079
remove aria-level from tablist
mk: this one was rempved from tab-list. looking for feedback from people
jn: i assume we can merge
anyone object?
none..
it will go from tab-list
jn: problem is that we have never tested it before.
https://github.com/w3c/aria/pull/1086
<jamesn> https://github.com/w3c/aria/pull/1086
update caption role for 1.2
scott: caption role previously was aria-described by.
This PR changes the current direction to set aria-describedby on the parent element to aria-labelledby to better match how a caption should be used.
added an example
a caption and figcaption are meant to provide an accessible name to their parent table and figure respectively
tried to take care of some stuff 901 as well
jn: are you good with this, everyone?
jd: I am happy
scott: aria-describedby was point to a caption.. this was the issue
didnt want this to go out
mk: that makes sense.
jd: in pull request there is an example.
<Jemma_> https://html.spec.whatwg.org/multipage/tables.html#the-caption-element
there is two paragraph children
in original pull request I quoted it.
we need author to not do that. I am the one who wrote this.
jn: are good to merge...
jd: +1
jn: https://github.com/w3c/aria/pull/1087
update introduction sentence to option role
any objection to merging?
none
will merge
https://github.com/w3c/aria/pull/1090
clarify use of alertdialog over alert roles
scott: a notification message, which could be an alert, could very well be persistent until a user decides to dismiss it. this text change is to help indicate that it’s OK for an alert to have a dismissal button to remove it from the DOM. But to specifically indicate that if an alert obsures content / requires a user’s focus move to the alert to close it to unobscure the content, that an alertdialog should be considered instead. additionally updates alert[CUT]
jn: Can we say if the alert takes focus when it is created then ..... To me - that is when alertdialog should be used - it isn't about whether it obscures other content
mk: is it not clear what a dialog is?
an alertdialg is model content
<Jemma_> https://www.w3.org/TR/wai-aria-practices-1.1/#alertdialog
<Jemma_> https://www.w3.org/TR/wai-aria-practices-1.1/#alert
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) Present: Joanmarie_Diggs jamesn Scott_O Irfan Dorothy harris Matt_King Jemma_ carmacleod Regrets: JonGunderson PeterKrautzberger Found Scribe: Irfan Inferring ScribeNick: Irfan Found Date: 17 Oct 2019 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]