<jamesn> scribe: CurtBellew

zakem, next item

New Issue Triage

<jamesn> https://github.com/search?l=&q=is%3Aopen+is%3Aissue+repo%3Aw3c%2Faria+created%3A%3E%3D2019-10-03+repo%3Aw3c%2Faria+repo%3Aw3c%2Faccname+repo%3Aw3c%2Fcore-aam&type=Issues

jn: 1088. put this in 1.3
... reasonable?

<CurtBellew_> Scribing issus

<CurtBellew_> jn 1083. can this wait for 1.3?

<CurtBellew_> so: I'm fine either way

<CurtBellew_> jn: we do need to do this but as soon as it's in a spec people can look at it, deal with it and implement it. 1.3

<CurtBellew_> jn: 1081. 2.0 issue

<CurtBellew_> jn: we should probably have a task of reviewing these in 2.0

<CurtBellew_> jakim, next issue

Spring 2020 F2F Planning - Hosts Requested

<jamesn> https://lists.w3.org/Archives/Public/public-aria/2019Oct/0010.html

<CurtBellew_> jn: emailed the group requesting potential hosts fora spring face to face

<CurtBellew_> jn : sometime end of april or beginning of May

<CurtBellew_> jn: potentially in western Europe

<CurtBellew_> jn: We have a couple potential host volunteers but we are still looking for a volunteer. Email James or Joanie

Resolving any comments in outstanding PRs

<CurtBellew_> jn: a bunch of outstanding PRs

<jamesn> https://github.com/w3c/aria/pulls?q=is%3Aopen+is%3Apr+-label%3A%22ARIA+1.3%22+-label%3Aeditorial

<CurtBellew_> jn: non editorial PRs taht are open targeted for 1.2

<CurtBellew_> jn: First one is new

<CurtBellew_> jn: 1080 is the first one

<CurtBellew_> jn: SH has requested a review from MK

<CurtBellew_> jn: can we mark it resolved?

<CurtBellew_> sh: I took the suggestion

<CurtBellew_> jn: once MK is done 1080 will be merged

<CurtBellew_> jn: 1079. wasn't on the list of ones to review initially .

<CurtBellew_> jn: I removed it from grid.

<CurtBellew_> jn: CB and Stegan, can you review this PR

<CurtBellew_> cb: Sure thing

<CurtBellew_> jn: the grid one is already merged. this one removes are level from tablet

<CurtBellew_> mk: check that there is even any slight possibility that it might be helpful to have it there. It's not necessarily if you could have tabs that would be nested but if it has a benefit to AT users

<CurtBellew_> jn: even if there is a benefit could you do this in another easier way. naming etc

<CurtBellew_> mk: sometimes two levels of tabs aren't near each other physically on the screen. This could be potentially helpful but it's unknown if screen readers can make use of that information

<CurtBellew_> mk: another thing is we keep it here for 1.3 and we open some conversations with nvaccess

<CurtBellew_> jn : 1072.

<CurtBellew_> jn: This is kind of complicated. Understanding the intended behavior for live regions

<CurtBellew_> mk: why aren't we exploring the deprecation of aria-relevant.

<CurtBellew_> jn: I agree but I'm not convinced that we don't still have this issue if we deprecate aria-relevant

<CurtBellew_> jn: It's about determining what will cause the aria-live to be triggered

<CurtBellew_> mk: someplace we need to cover it

<CurtBellew_> jn: we should postpone this to 1.3

<CurtBellew_> mk: the practices task force can help out with this

<CurtBellew_> mk: we should create a page that will demonstrate which case will trigger the aria-live

<CurtBellew_> jn: any objections to moving 1072 to 1.3?

<CurtBellew_> ... silence ...

<Jemma_> no objection

<CurtBellew_> jn: done

<CurtBellew_> jn: 1071. any objections to merging 1071?

<CurtBellew_> jn: We probably need to log something against authoring practices

<CurtBellew_> mk: we do. I put it on a todo list to do something like that

<CurtBellew_> jn: when I merge it I'll not merge in to stable and make that change

<CurtBellew_> jn: 1070. I believe that was mostly editorial

<CurtBellew_> mk: I'm in the middle of my review

<CurtBellew_> mk: 2/3 of the way through. will be done shortly

<CurtBellew_> jn: I'll wait for that

<CurtBellew_> jn: 1069.

<CurtBellew_> jn: this one needs discussion

<CurtBellew_> mk: yes it does

<CurtBellew_> mk: there is some debate as to where we need aria-checked and aria-selected

<CurtBellew_> mk: but we don't seem to need to make changes here

<CurtBellew_> jn: and it's too late to make the change in 1.2. if it's not unanimous let's postpone that conversation to 1.3

<CurtBellew_> mk: option and treeitems don't need to be checkable by default

<CurtBellew_> mk: having a default value defined for the property isn't a good idea. It should be undefined

<CurtBellew_> jn: why can't we have it not defined on the property for checkbox

<CurtBellew_> jn: but on option and treeitem have it be what it is today

<CurtBellew_> mk: the default would be "undefined"

<CurtBellew_> default for option and treeitem would be "undefined"

<CurtBellew_> mk: is checked a required property for the others?

<CurtBellew_> jn: Yes it is

<CurtBellew_> jn: In the draft it is yes

<CurtBellew_> mk: then having the default value of section 6 be undefined would be ok

<CurtBellew_> mk: This PR removed that value and we need to restore undefined

<CurtBellew_> jn: I believe so

<CurtBellew_> sh: Just close it down right?

<CurtBellew_> jn: wasn't there something else to be done?

<CurtBellew_> sh: I"ll look at it again. I'll re-add that line

<CurtBellew_> jn: Everyone ok with that?

<CurtBellew_> ... general murmur of agreement ...

<Jemma_> ;-)

<CurtBellew_> jn: remove allowance of group in list. what's waiting?

<CurtBellew_> jn: 1053

<CurtBellew_> jn: MK made a comment. SH has made that change

<CurtBellew_> jn: MK are you ok reviewing it again?

<CurtBellew_> mk: I'll approve it now

<CurtBellew_> jn: combobox. not yet. moving on

<CurtBellew_> jn: 1023. some discussion in this mostly around adding back a few things

<CurtBellew_> jn: These used to be global

<CurtBellew_> jn: based on comments I've added back all 4 to roll application

<CurtBellew_> jn: I've added aria-disabled on tooblar

<CurtBellew_> mk: on the toolbar element itself?

<CurtBellew_> sh: I referenced that becuase it's allowed on menubar and everything would be disabled. toolbar is a collection of controls and they could be disabled.

<CurtBellew_> sh: a group is a standin for field sets

<CurtBellew_> sh: it should probably allow to stay in group

<CurtBellew_> sh: meaning that all of the elements within that group are disabled

<CurtBellew_> sh: seems like there could be use cases to make sense

<CurtBellew_> jn: if we do want parody with fieldset ...

<CurtBellew_> sh: I tested aria-disabled on group this morning and it does seem to work

<CurtBellew_> sh = Scott_O . moving on so = Scott_O

<CurtBellew_> mk: does it make everything inside of it not focusable?

<CurtBellew_> so: yes takes it out of the tab index

<CurtBellew_> joanie: adding something to the parent and having it propagate to children. Were you testing that in AT?

<CurtBellew_> so: voiceover and JAWS returned that the children were disabled

<CurtBellew_> joanie: have the user agents implemented this?

<CurtBellew_> so: I'll have to do further testing on this

<CurtBellew_> joanie: I'm wondering if those AT in particular are doing something

<CurtBellew_> jn: if we change this we will break things that work now

<joanie> https://w3c.github.io/aria/#aria-disabled

<joanie> Does not say anything about user agents MUST propagate ...

<CurtBellew_> jn: looking ahead to parity in 1.3. fieldset supports disabled

<CurtBellew_> cm: it's already allowed on radio group

<CurtBellew_> mk: does this work on any composite like a grid?

<CurtBellew_> mk: if you put it on a grid it just marks everything disabled?

<CurtBellew_> jn: if it's disabled then you probably don't want to read it

<CurtBellew_> Nah, just me typing before thinking :) . sorry about that

<CurtBellew_> mk: does a link support aria-disabled?

<CurtBellew_> jn: We've discussed it and I can't recall

<CurtBellew_> mk: if it propagates then you would need to make sure that any of those children would support aria-disabled

<CurtBellew_> mk: does it work in HTML?

<CurtBellew_> jn: No

<CurtBellew_> mk: are links without an href actually a link?

<CurtBellew_> jn: right is it a link or a button. my thought has always been based on how it looks

<CurtBellew_> jn: look like a button or a link? then it should be represented as that

<CurtBellew_> joanie: we don't need link as a role

<Dorothy> role=link = not recomended

<CurtBellew_> joanie: we have the image role as well. some of the roles need to be reviewed.

<Dorothy> use html5 whenever possible

<CurtBellew_> mk: link and image both have these kind of problems

<CurtBellew_> mk: I think I agree with the SO point.

<CurtBellew_> mk: links in a grid will not be disabled because links don't support aria-disabled

<joanie> In summary: Assigning a role on an element doesn't magically cause all the expected accessibility APIs to be implemented -- or implementable.

<CurtBellew_> mk: that's something developers need to be aware of

<CurtBellew_> mk: authoring guidance

<CurtBellew_> mk: so all of the children need to be checked if they support aria-disabled.

<CurtBellew_> jn: Stefan is on the q

<CurtBellew_> jn: It looks like your concerns were addressed as those were added

<CurtBellew_> jn: Stefan, please review

<CurtBellew_> cm: I'll do an update. I've got it prepared

<CurtBellew_> jn: two ways of going forward. put off aria-disabled until we're done or someone can propose something that's not controversial around it and we can include it

<CurtBellew_> jn: we re-add aria-disabled. we separate issue for what user agent support needs to be potentially in 1.3

<CurtBellew_> bg: We do have a real world case where a client had links that were disabled

<CurtBellew_> bg: they were styled differently and had aria-disabld on them

<CurtBellew_> jn: can you add those comments to the PR, BG?

<CurtBellew_> bg: yes

<CurtBellew_> jn: 3 minutes left

<CurtBellew_> jn: status. role parity we have a bunch that are done and a bunch to do. if you can help out we really need to help

<CurtBellew_> jn: we still have 63 open issues.

<CurtBellew_> jn: a bunch have PRs or are role parity

<jamesn> https://github.com/w3c/aria/milestone/10

<CurtBellew_> jn: still some open in milestone 10

<CurtBellew_> cm: pull 1023 question

<CurtBellew_> cm: context menu. does it require aria-haspopup

<CurtBellew_> cm: a bunch of old code does that but it seems to have been taken out of the spec

<CurtBellew_> cm: do we need aria-haspopup for context menu

<CurtBellew_> jn: my opinion is not it does not

<CurtBellew_> stefan: we have the same issue here.

<joanie> I agree with james

<CurtBellew_> stefan: the regular button doesn't seem to get announced as having a context menu

<CurtBellew_> so: we have been through a similar line of conversation previously

<CurtBellew_> jn: will we be clarifying the spec by saying it's not allowed

<CurtBellew_> so: that's my take on this

<CurtBellew_> * I've got to run as well

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/obection/objection/
Succeeded: s/parody/parity/
Succeeded: s/lol. oops//
Succeeded: s/not intentional//
Succeeded: s/me thanks//
Default Present: Joanmarie_Diggs, jamesn, Stefan, Scott_O, Jemma_, jongund, Dorothy, carmacleod, Bryan_Garaventa, Matt_King, CurtBellew_

WARNING: Replacing previous Present list. (Old list: Joanmarie_Diggs, jamesn, Stefan, Scott_O, Jemma_, jongund, Dorothy, carmacleod, Bryan_Garaventa, Matt_King, CurtBellew_)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Joanmarie_Diggs, jamesn, Stefan, Scott_O, Jemma_, jongund, Dorothy, carmacleod, Bryan_Garaventa, Matt_King

Present: Joanmarie_Diggs jamesn Stefan Scott_O Jemma_ jongund Dorothy carmacleod Bryan_Garaventa Matt_King CurtBellew_
Regrets: HarrisSchneiderman IrfanAli MarkMcCarthy
Found Scribe: CurtBellew
Inferring ScribeNick: CurtBellew

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 10 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.)