Meeting minutes
<jamesn> - Please register https://
<jamesn> - ARIA sessions Scheduled Thursday Oct 28 - (1 hour) 7am Pacific / 10am Eastern & (2 hours) 9am Pacific / noon Eastern
<MichaelC> https://
[New Issue Triage](https://bit.ly/3iTXLO7)
jamesn: agrees
James Craig: this change could happen in 1.2, but the related issue (changing "Indicates" to "Enumerates") would be dependent upon our decision in the related IDL discussion.
Jamesn: Based on jamesn's suggestion, I'll make the one-word edit, and raise the related definition change as a new issue (comments made in ARIA #1625)
[New PR Triage](https://bit.ly/3lCogcz)
jamesn: no new PRs asks for anyone to bring forward
jamesn: moving on
[TPAC 2021](https://github.com/w3c/aria/issues/1482)
<jamesn> - Please register https://
<jamesn> - ARIA sessions Scheduled Thursday Oct 28 - (1 hour) 7am Pacific / 10am Eastern & (2 hours) 9am Pacific / noon Eastern
<jamesn> https://
cyns: proposing ideas for TPAC discussions on issue 1482
jamesn: we could run some more meetings if these are not proposed as topics
jamesn: i will not be available to run them but someone else could
cyns: will propose a time/date for these meetings
cyns: Canvas seems stable at the moment
<IrfanA> AT https://
<IrfanA> Browsers https://
janina sajka: has a proposed discussion on how content is pronounced and old technology that is bringing challenges
jamesn: propose a time/date
jamesn: please be concious of timezones with scheduling
jamesn: AT vendors would need to be invlved for various countries and continents
jamesn: propose the schedule in a github issue so that various companies can have their input on the date/time
IrfanA: need people from browsers and AT vendors
James Craig: while we have the AT people there is there room for a cross group meeting
IrfanA: need specific people from the aria group
janina sajka: will send specific invites to individuals
janina sajka: difficulty registering to TPAC
james
jamesn: difficulties may be intermittent
Charter License Changes. Preparing CFC for change to Software and Document license.
jamesn: In the issue with our charter there are 3 votes of support for changing to new license
jamesn: objections?
jamesn: no objections
jamesn: this will goto charter review and objections may be heard there
[Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)](https://github.com/w3c/aria/issues/1598)
jamesn: there have been a few updates to this
james craig: i had not seen the comments
jcraig: there may be an implementation issue here
<jcraig> From #1598 Option 1 "Spec could state that the nullable enumerated attributes reflect (HTML definition), and the other nullable attributes, ~"Return the value of the attribute if present, or null otherwise." Downside to this path is that none of the implementations match the enumerated attributes IDL now, so those would need to be removed from the PR, or ARIA 1.2 CR would need to wait on two implementations for the enumerated validations.
<jcraig> Note: validation for default missing value and default invalid value is currently handled by the backing accessibility implementation in the engines, and not by the IDL implementation."
jcraig: option1: would seem to be the best solution. JC will describe
jamesn: option1 still has the same issue though?
jcraig: same issue but less overall issues
jamesn: it might not be fewer issues than with option2
jcraig: enumerated ones would be easier, just remove the question mark
jcraig: for non enumerated we don't have a logic way of specing that
jcraig and cyns get into technical discussion around empty vs nullable values
jamesn: there are nuances with empty and nullable in aria 1.3 for aria-desrcribed-by
jamesn: in option 1 & 2 there will be issues with that and the algorith to work around it would need to be defined
^ jcraig
jamesn: we have an algorith already
jcraig: there is still a logic hole but it may have been addressed, looking it up
<jcraig> https://
cyns: good idea or bad idea? what if we gave a default value of null?
jcraig: sections define linking patterns and gives it a format and there are exceptions to that format but we could possibly modify some sections to fit the scheme better
jamesn: this section is normative
jcraig: i will respond to the comments
jamesn: anything else to add?
jamesn: put a link to the meeting in the issue to elicit a response as no direct contacts exist to those that need to attend
[clarify img naming steps](https://github.com/w3c/html-aam/pull/322)
scott ohara: drops title attribute if alt name is empty
scott ohara: firefox does not want to drop the title
scott ohara: chromium and firefox are conflicting on this
matt king: is there any data we could use to help with this?
matt king: this has been communicated for years that this is what empty alt text means
matt king: trying to think of a real world case of needing a title on a decorative image
jamesn: not needed
matt king: let's get a consensus on this issue
scott ohara and aaron leventhal discuss the nuances between chromium and firefox's level of exposure of the title and description of the image
matt king: we should align the experiences across the browsers if possible
discussion around author error and what to tell the developer in these cases
jcraig: need to reference the priorities of the constituents because the author may be confused but we need to prioritize users over authors
matt king: users get flooded with titles that get in the way
jamesn: the spec says to expose title as description in some cases but there is a discrepancy between browsers
jamesn: calls time
<aaronlev> talking among googlers here, we'd be ok with either the firefox or chrome approach
<aaronlev> as long as there is consensus