<StefanS> present#
<scribe> scribe: sarah
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
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
carolyn: are there any objections to this? It's not a must, it's a should
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
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.)[End of scribe.perl diagnostic output]