Meeting minutes
<jamesn> zakimm drop item 6
<jamesn> zakim drop item 6
New Issue Triage
Valerie: First issue is deprecate rather than remove aria-expanded for static roles
JN: He's concerned that we are making ARIA backwards incompatible
… I have some sympathy. We generally don't deprecate things that don't work
… He watns to talk about this at TPAC with ACT
JC: I can see why checkers don't want to throw errors for things that were valid
<melsumner> I don't mind adding a deprecated flag. As a tooling author this is useful.
JC: Maybe there is a middle ground, maybe we don't need to force checkers to throw errors, we could do with warnings
<melsumner> I should say, I don't object to the addition of a deprecated flag, as a tooling author this would be useful.
JN: We can add messaging that these were removed in version xx, like other specs do
JC: And then have an RFC line "checkers may ..."
JN: RTeasonable thing to chat about at TPAC
<cyns> +1 to "checkers may... "
Valerie: Will add F2F candidate
JC: What's the difference?
JN: Originally we had both, now we onlyuse F2F candidate
Scott: It's weird to have to deprecate an error in the spec
… This was published already
… Are we adding a Note to 1.2 or this is adone issue and this is how the process needs to go forward
JN: Agree with you, I don't think we shouldd go back on this one, but this is whatwe need to discuss at TPAC
… Maybe we learn a better way forward for future cases for including clearer messages
Scott: But this is an error, this is why it was changed
Valerie: Second issue: Make aria-braillelable and aria-description prohibited on non-generic
Matt: I have on my ToDo list to go through all roles where this is happening, I wonder if we need to raise a separate issue
JN: That wouldn't be too hard, I would treat aria-describedby and aria-description separately
Matt: Everywhere aria-braillelabel is prohibited, aria-label should be prohibited too
JC: Are there any aria scenarios that allow nameFrom: values that do NOT include nameFrom: author? I can't think of any offhand, but if there are, we may not want to prohibit aria-braillelabel in the exact same scenarios as aria-label. [No response. Will address as a bug if we discover a problem later.]
JN: I'll be working on this
New PR Triage
Valerie: This removes things from the terms list. I requested a bunch of reviewers
<jcraig> web-platform-tests/
Valerie: Follow-up from our F2F discussion. IF you are interested in this, please take a look
JC: Is there a way to tag them so that when people post PRs on WPT repositories this gets flagged?
JN: Are we sure we always label this? I could query these on my script if there is a label
JC: I'm working with the WPT team to have a label that applies to all directories
JN: Give me a list of labels. We can put an agenda item with a link for people to see those easier
JC: Anyone wanting to work on WPT?
Melanie and Scott say they want to work on these
Deep Dive planning
Valerie: We had Deep Dive today on ARIA Modal
… Another is rethinkg how hidden is aria-hidden
… Anything else on these topics?
Matt: We didn't really address aria-hidden this morning
Scott: That'd be another good topic sometime later
Aron: We can discuss further how to better solve these problems from a browser's perspective
… A few issues are already raised
Valerie: Can you find those and link them here?
Aron: yes
Valerie: The other item is Windows Mac differences in presentational roles
JC: I prefer to do that after TPAC
Siri: Is there a palce where we can look at the Deep Dive minutes?
<spectranaut_> minutes for previous meetings: https://
Volunteers for ARIA test writing?
Valerie: We have the ability to write some test for AccName
… The documentation written by James Craig is in the ARIa folder
<aaronlev> I put the links in the ARIA issue
[[link]]
<Adam_Page> https://
Valerie: Writing tests is a way to get familiar with the specification
JC: These tests are simple. Just a bit of HTML with the role. Then they has a class and a call to JavaScript
… Those who know ARIA and HTML can write them easily
JC: Every test is able to find new bugs in browsers, so these are becoming very useful
… Running the tests is traightforward
… We are wanting to look for volunteers that we can assign tasks to
Rahim: Happy to do that. How do we test across browsers?
JC: Chrome Canary, Safari Dev Preview, and Firefox Nightly
MArio: Is it possible for blind people to write tests?
JC: Yes, you have to be familiar with command line scroll back
… We do have documentation
… We can actually update the documentation
JC: I have Melanie, Rahim, and Mario. If you have a particular one that you are interested in, just pick it up
Rahim: I can do the widget role
Discussion tracking for ARIA Notification proposal
<spectranaut_> https://
Valerie: Explain identify guidance for required and expected screen reader interaction
Doug: : I just ported this to wai-ig
… WE were talkking about the expectations for screen reader users
… Live regions are implementeed differently
… Even if non-mandatory, I think it would be good to have some guidance
Matt: What's the path here? Are you looking for some place where we can put screen reader expectations? It sounds like it does not belong in the spec API
Doug: : Not sure, worth keeping consistent with past ARIA habits
Matt: It's not clearw to me where the notification specification is going? Not part of ARIA, right?
Doug: : Yes, I don't think this has to have the ARIA tag
Doug: : At a minimum, it would be referenced in the ARIA live regions section
Matt: Not sure if deprecation is the right thing
JN: Certainly we don't need to deprecate all of the live regions stuff, but at least point people to what is nowadays been done with live regions
Mario: The definition of live regions is good. Why we cannot just make sure people do what we say should be done?
Matt: There a reliability issue, there are so many way these can be coded when it comes to modifying the DOM. Not all of these work consistently.
… That is an implementation issue
… There could probably be room in ARIA to provide guidance as to how screen readers should implement this
Doug: : I could propose my interpretation ofwhat I believe screen readers should do
<cyns> 1+ to clear expectations for screen-reader interoperability
Mat: I think screen reader expectation need to be really clear, this is a good opportunity for us to get rid of the unnecessary variations in notifications
… Question of wher e that belongs we can decide later
Doug: : Youwould change it to requirements
Matt: Yes, that's an opportunity to move forwads in interoperability
MArio: ARIA specification does not define screen reader requirements
Cyn: I don't think there is other places for this type of guidance
Matt: This goes back to a F2F discussion we had, where we decided we do want to have some guidance
Siri: Are you saying the current API has issues? How is this different with what we have now?
Doug: One of the problem is that the current implementation is spotty
… IF the text is on the screen is one thing, if it is not on the screen is another thing
… They do not necessarily know when the AT has acted on it, not sure then when they could remove it from the DOM
… The goal is to say to the WebApp when there is a string and when they need to speak it
Siri: Screen reader has to read from the DOM irrespective of whether it's on screen
Doug: I don't think live regions where originally designed for what they'are being used now
… It's difficult to make screen readers aware of the notifications
Melanie: aria-live is already annoying as a user
… When I am reviewing author's code most of the times they are using it in places where it's not designed for
Doug: This is to make it easier for authors to implement these things
… And educate them on when they should and should not do this
Matt: From APG perspective there is little we c an say because there is no consistency