<StefanS> present#

<scribe> scribe: sarah

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

James: we have three new issues since last week, 1322: consider allowing ARIA on fieldset elements
... Stefan: your comment?
... this is specifying aria-erquired on a fieldset, and you commented on aria-disabled

Stefan: I thought I read something related about aria-disabled on a fieldset

James: I mentioned aria-disabled about how that actually does work on a fieldset. If you specify it, it makes all the child things disabled, which is not the same as they were asking this aria-required to do. I think required would be ambiguous, and we should close this issue

jcraig: I think the readonly issue is linked, and arguments in that issue apply to this one

Stefan: someone said this was an HTML issue and not an ARIA issue, so I thought if we want this, it should be reflected in thehost language

james: I don't even understand what putting required on a fieldset means. This isn't asking for everything to be required, but only one element
... I was hoping we could just close this issue

jcraig: I think we should close the readonly issue as well, because even then the native inputs have meaning if the attribute is left off. So even if the container has it specified, it wouldn't mean anything

stefan: if something is available in ARIA, it should also be available in the host language in the long run
... if there's no chance of getting aria-required in the host language, then it makes no sense here

matt: I don't understand that argument, we have mountains of stuff in ARIA that will never be in the host language

james: I can see the validity of the argument when there's a similar feature in HTML and it doesn't allow that exact usage of it, and that would conflict with the ARIA usage

matt: yeah, I agree we shouldn't create conflicts

james: closed issue

isabel: question: say there's a situation where there's two inputs, and only one of them is required but not both, how would you mark that up?

james: there's no programmatic way of doing it without using text
... there's no standard visual way either

jcraig: they'd have to describe it in words, since there's no visual way to mark it up

joanie: I'm in favor of closing this issue. We allow this in radiogroups, so what if we had something similar to radiogroups where you have to pick one

jcraig: I agree the use case is valuable, but I don't agree it should be in ARIA. If and when it's defined in HTML, we should make sure that it works with custom elements in ARIA

<harris> +1 to jcraig's point

james: and browsers need to find a way of denoting that visually if HTML is going to do that

joanie: and that already exists in HTML for radiogroups?

james: I think in a radiogroup if you mark any button as required, one of them is required
... next one, 1321, user agent editorial issue

carolyn: I could take it, but I won't get to it until January

james: can this be 1.3 then, or should it go to 1.4?

melanie: I don't mind taking the issue, but it looks like it's blocked on something else getting merged

carolyn: yes, though it would be fine to work around that

jcraig: what's the relation to the word mainstream?

carolyn: Matt raised that issue on 1351 PR, I was saying UA should provide landmark navigation, and Matt said "why does it say mainstream user agents" so I was happy to take that out but I noticed that there are several other instances of the word mainstream in the spec. So maybe they should all come out

james: so my understanding of the word "mainstream" user agents was browsers, and "user agents" included AT

matt: back in the day we had that conversation, but if you look at all instances of the word user agents here, it always means browsers
... to the extent that an AT can be a browser, then it just becomes a user agent and we shouldn't distinguish between the two

jcraig: I would probably vote at least one usage of mainstream in the spec. The way I use it is when I as a user want to emphasize that we're not just talking about AT here. I think it's more for a reader, than the definition in the spec
... I use that particular phrase frequently, so I want to know why it's considered outdated usage

carolyn: so many places in the spec say "user agents do this, AT do that", so they're separate. This is my first time hearing that user agents might mean AT

matt: what we mean by that is that some AT do the same things that browsers do, so they can act like user agents
... so if you develop an AT, and IF that AT does browser things, then that "must" applies to you
... there are other things that apply to ATs that don't apply to user agents, so you can write software that is both
... an example of this now is Tobii. They are an eyegaze, and they're developing their own browser, but it is an eyegaze browser. So that is a browser and is an AT

carolyn: so I think we should delete mainstream, because isn't that insulting to those developers to say that they're not mainstream?

jcraig: I agree with Matt that when it's used in a normative statement, i.e. may or should, we should remove it. I don't think we should get rid of it in all instances of prose
... I don't know any AT developers who are oblivious to the fact that most users do not use AT

<jamesn> "Any software that retrieves, renders and facilitates end user interaction with Web content. This definition may differ from that used in other documents."

james: I just want to note the definition of AT in the ARIA spec (says definition)

jcraig: and JAWS would then count as a UA for sure, since it reads the DOM and does the virtual buffer thing
... I might consider voiceover a UA since it renders certain things, but it's not necessarily a web user agent

matt: JAWS does have a virtual buffer but it's based on the a11y API, so I don't know if it's still a UA

james: should this be 1.3, or should we push to 1.4

carolyn: call it 1.3

james: next is 1320
... again, a 1.3 and is it editorial again?

carolyn: yeah mostly, but not completely. I need to discuss with Matt. I made the change in 1315, and I thought it was correct. But maybe there was another paragraph or note that was added on the end that confused me

matt: yeah, 1.3

james: PRs now: there are none
... next week, do we want to have a deep dive? Trees we're scheduling for the week after next
... and then we want to see if there are any other deep dive topics we want to talk about

<jamesn> https://github.com/w3c/aria/labels/deep-dive

james: topics in a query with the deep-dive tag in the aria repository
... forgot to put the query in the agenda
... I'd love to talk about bringing voiceover actions to the web sometime

jcraig: that might require more than one deep dive

matt: I really want to be part of that one, so I hope you don't do next week
... this particular pandora's box has become more important to me in recent months
... to me, this is related to ways of ... let's not go into it now. I'll just say "hover"

jcraig: hover, drag n drop, privacy
... and related to if you trigger actions, are you exposing them

matt: I could do something async in that issue. It might be good for us to have some async conversation prior to a deep dive on this

james: let's schedule that for a later topic, and not have one next week

jcraig: I know a lot of people have a lot of stuff leading up to TPAC, so after TPAC sounds good

james: so conclusion no deep dive next week

thanks Mark :D

[Generalize AccessibilityRole/AriaAttributes IDL](https://github.com/w3c/aria/pull/984)

jcraig: I think this is a 1.3 issue that still had a little bit of work on it

james: this is the one that they say is blocking the WHATWG 4658 issue we talked about in the web components meeting

carolyn: I think it's ready to go, I made a tiny suggestion and dominic has committed that change
... and before that he said merge at your convenience

james: so if everyone's ok, I'm going to merge this into the main branch. It's not going to be 1.2, it'll be a 1.3 thing. Any objections?

all: nope

james: if there are no objections, I'll merge that later

carolyn: james craig you're still on there to review if you want

jcraig: I think I reviewed at an earlier version and I'm not concerned about it

Meaty topic for next week

carolyn: are there any objections to this? It's not a must, it's a should

landmark navigation

carolyn: and it doesn't even define landmark navigation, so UAs are free to choose if they want to support only elements that have landmark meaning, or if they want to support roles
... does anybody object to us saying this?

james: we're looking at you, james (craig)

carolyn: aaron's not here either

melanie: I was wondering, what's your ideal outcome?

<jamesn> https://github.com/w3c/aria/pull/1315

carolyn: my first stage ideal outcome is that any user, not just a screen reader user, can use a keyboard to jump around the page from landmark to landmark. So there's a character shortcut key that browsers will provide without an extension -- right in the browser. And if the user types that shortcut, they'll go to the next landmark
... so that's my initial goal. Some year down the road maybe it would be awesome to have essentially a map or sidebar that you could open up with another browser key, and it would show you all the landmarks on the page. And that would help users with cognitive issues, or any users understand the page
... and they could jump to a specific nav, and understand the page better. So that's kind of next step
... the absolute blue sky is you can navigate to headings too, but that's a pipe dream

stefan: I remember Opera had some sort of keyboard nav way back. I don't know if they had landmark nav

<jcraig> I think this is the triage list we're referencing now, is that correct? https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22ARIA+1.3%22

james: they don't even have the keyboard nav anymore, that was the old engine
... they were single letter keystrokes

carolyn: oh, that's too hard, you can't do that

james: so anyone object to merging this?
... we don't have any positive reviews yet, do we?

jcraig: going back to the mainstream one, in the instance of 1315 removing it makes sense
... the comment I'm adding to the second editorial issue is that we should just take each instance individually
... and removing it if it really adds nothing

james: it would be good to have a couple positive reviews on 1315 before we merge it

matt: I didn't request changes, but I didn't give a thumbs up or down. Now that it's changed, I can add a thumbs up review

james: and we were asking people who worked on various UAs to see if in their orgs there would be any issues with this, since we don't want to rock the boat

jcraig: I can comment on that. I think the response I got was that this should be a may
... I didn't get a response back on whether this should be a dealbreaker, so it's softer than that. However, it's firm enough that I'm not going to put a happy postive review

carolyn: it actually was a should in all but the abstract role at the top and the region role. If you look at the files changed, it used to say user agents should treat elements with the role of banner as navigational landmarks

car: but I guess it didn't say that they should have keyboard shortcuts

jcraig: so browsers already do treat them as nav landmarks. But it's the change to saying should have keyboard shortcuts
... so I'm happy to sit back and let you poke the beark
... and see if you get adoption in other browers. I may be able to make more of a case for it if other browsers do it

carolyn: someone went first with tab browsing, and it took off

jcraig: I'm curious if you can do it without any sort of visual overlay

matt: if it was a key and it moved focus, there's some stuff to be defined, like does it actually focus the region in the same way that the body gets focus when page loads

carolyn: what I'm saying is it should move the sequetial focus nav starting point
... so it's like someone mouse-clicked on the region

matt: yeah, we should probably not talk about the implementation details, but there are implementation details that matter if they're done differently in different browsers
... so if you lose the visual focus indicator, there are implications to disappearing focus

melanie: where would this fit in the run loop. Because if I've carefully determined where focus is going, then it goes away based on keyboard interaction, then that might be breaking stuff

jcraig: the caret should follow if the focus does not. So if you move point of regard, the focus navigation should start from there
... because when focus is blurred, technically focus goes back to the body. But now implementations are smart enough to move focus forward or back from the caret

carolyn: I think that's the same as the focus nav starting poing

jcraig: that's how in-page links should work
... some of them work, and some of them don't

curtis: I'm thinking of that in terms of the focus right. Usually when I click an in-page link, I don't get a focus ring
... there's no way to let a user know where they are, because you're going to region but you're not identifying it

jcraig: different browsers and sites can show this in different ways
... all of them also usually scroll that element to the top of the view. But if there are multiple columns, or it doesn't scroll that far, it might not be clear
... so there are ways to do it without the focus right

matt: regardless though, you want some visual treatment

james: but we don't have to solve that now, right?
... so if there's no objections to merging this, should we do it?

jcraig: I would recommend waiting for a response or non-response
... mine is not the official response, it's just how I read the lack of formal response

james: and while should is a normative statement, so is may, and it's still not a must

jcraig: the risk here is that there might be a formal objection, and it would be determined at the advisory board level
... I don't think that's a big risk, it might just raise some tension here and there

james: maybe we can raise it at the right time, and get any feedback before we go to CR

matt: I don't know why there would be any objection
... why doesn't one of the browser companies just say they'll be a leader here

jcraig: this is the first time ARIA is defining mainstream UA behavior, as far as I'm aware

james: but this is not a must, so we're not defining it as such

matt: defining mainstream UA behavior, but not defining a behavior that affects how the page operates
... it doesn't affect the rendering of the page, or anything that browsers have done
... it's so different from ARIA saying for example, if you provide a radiogroup with no HTML radio input, that the browser has to provide arrow key behavior. If you do that, you may be breaking contracts with authors

<carmacleod> https://w3c.github.io/aria/#ua-support

matt: and in this case too, if browsers provide a key, the cool thing would be is if there was some keyboard convention then authors could just override it

carolyn: James Craig, I pasted a link in the chat, UA support in the ARIA spec. Could you look at that, and I'll read the 3rd paragraph
... (reads third paragraph)

The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities.

jcraig: I wrote it
... the initial draft was user agents may, and I changed it to user agents might
... so I wrote portions of this, and I do remember editing it
... this is actually what I was referring to. It neither requires nor prevents
... should is a requirement. It's not a must, but it is a requirement. Anything more than may is a requirement
... so this would be a direct contradiction

carolyn: I'm going to look through all the shoulds in the spec and see how many UAs don't do

jcraig: that's an ambitious exercise
... most of them are formatted in the way that user agents should expose them as navigation landmarks, and the way they do that is by exposing them to the accessibility tree, so that's a valid should
... so this is one place where the word mainstream does clarify what the intention is

matt: I kind of agree with your saying mainstream. I think it's enhancing in this particular case

jcraig: I definitely did an exercise of taking out may, should, and must in prose. It's easy for those to slip back it, but that should be done once a year

carolyn: the html spec has a tool that removes those on commit

james: the html spec doesn't require uppercase

jcraig: respec should be able to do that as well

james: I don't know about that with respec. Anyway, it doesn't really matter
... so what are we doing about this

carolyn: getting a response from Aaron and the Edge team

james: so I'm not merging it. Carolyn, I'm sure you'll bring it up again

1.3 Triage

<jamesn> https://github.com/w3c/aria/issues?q=is%3Aissue+is%3Aopen+no%3Aproject+milestone%3A%22ARIA+1.3%22+sort%3Acreated-asc

james: the first one that we're looking at is #842: no aria property for default or submit button
... in HTML, a submit button is exposed as the default, and as far as I'm aware there is no ARIA equivalent
... is this something we need?

james is there a use case for this?

matt: I don't understand, what does it do for users?

james: 1, how is this shown visually?

james, is this a case of the primary button thing, and can we merge it into one?

stefan: we do style default buttons in the UI with a different background color

james: it sounds like if you have a visual usage, maybe we should have it?

stefan: could we have a variant of roledescription? Like "default button". This is a black hole of what is allowed in roledescription

sarah: is there a semantic way a default button in a dialog is exposed?

stefan: yeah, JAWS has a key you can press to read the default button

james: is that an example of what it might do, or what it does do? Does it actually do that, that JAWS key + E reads the default button?

stefan: ask Aaron that

jcraig: so I'm not aware of a similar feature in voiceover, though there mainstream behavior on dialogs in AppKit dialogs and JS dialogs like confirm and prompt that the return key on mac will always trigger the default button
... quick aside, maybe we should consider a cancel button in addition to a default button
... I believe it was mozilla that proposed a default button in HTML, maybe 5 years ago, and it was dismissed
... I don't recall the specifics. I think this would be a good candidate for ARIA even if it was dismissed, but we should go back and find the details of why it was dismissed

james: I think we can merge this with primary button
... many design systems have different styles like primary, warning, etc
... maybe we should point this to the Open UI folks who have done that research

jcraig: this is a unique instance in ARIA where like main, HTML dismissed main initially and the ARIA group said it's too important. Then it went back in the HTML spec because Steve F and others made a case for it. This is another where there's a clear case for it in the accessibility side of things, because visual users get it

james: I don't thinkw e want to take this so literal as the default button, but also the call to action button that may not be the default button

jcraig: I think james has made a good point that this is a bigger issue than delete or primary

james: we are now five minutes past the hour. i don't know what the conclusion is about this. Seeing we already have an item on the deep dive list for this, so we can punt to then

This is scribe.perl Revision of Date 
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/teh /the/
Default Present: Irfan, Joanmarie_Diggs, pkra, StefanS, jamesn, Scott_O, Matt_King, harris, James_Craig, sarah, Juliette_McShane_, MarkMccarthy, carmacleod, CurtBellew
Present: CurtBellew Irfan James_Craig Joanmarie_Diggs Juliette_McShane_ MarkMccarthy Matt_King StefanS carmacleod harris jamesn sarah
Regrets: pkra Scott_O JonG
Found Scribe: sarah
Inferring ScribeNick: sarah

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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.)