Closed jnurthen closed 5 years ago
For https://github.com/w3c/aria/issues/1021, we need to at least decide which milestone (1.3 or later). If time, need to discuss in more detail.
I propose a single segment on the topic of "Effects of ontology on table and grid" for discussing approaches to resolving the following 3 issues:
I don't believe we need non-WG participation.
I think it will take a solid hour or more to clearly layout the problems and weigh options.
<select>
* [HTML-AAM: select element should map to listbox role regardless of presentationThere are several topics of discussion related to the above issues. I will organize them into an agenda for this segment.
Discuss long term options for making it easier for authors to get the practical information they need about developing accessible sites.
Currently, WAI-ARIA Authoring Practices, Using ARIA, WAI Tutorials, and possibly other resources, such as some WCAG techniques, all offer valuable information to authors. While there are some advantages to having separate resources, there are also significant disadvantages, especially to authors who fail to find relevant information simply because of the way the separate deliverables are scoped. There are also downsides to WGs to having separate but sometimes redundant objectives.
I would like to discuss group related topics for 20 minutes, including:
listitem
role seems to be missing directory
as required context rolearia-details
precedence over aria-describedby
We had to pull aria-details guidance from APG 1.1 Release 4 because it is not clear when it is beneficial and what the anticipated screen reader support might be like. Initially, it was part of a section on accessible descriptions. However, it is unclear what the relationship between descriptions and details is. We need to answer some basic questions for authors, such as:
Rossen has suggested Tuesday 11:00 - noon for a joint meeting with CSS, ARIA, and APA. https://lists.w3.org/Archives/Public/public-apa/2019Aug/0027.html
We should reply to him as soon as we know this is doable.
EDIT: UPDATE: I replied stating the time is confirmed. Unless we hear otherwise, we should plan on this time.
I'd like to discuss aria-brailleroledescription. https://github.com/w3c/aria/pull/924
DPUB meeting is 9-9.30 am on Tuesday.
I'd like to propose:
Suggested time: Monday, right after lunch (14:00)?
cc @annevk @domenic @foolip @sideshowbarker @mcking65 @jnurthen
I'm interested in extending WebDriver with commands that take advantage of ARIA semantics and the APG. This could be a compelling incentive for developers to use accessible patterns.
My colleagues @spectranaut and @zcorpan will be available to lead a discussion at TPAC, and WebDriver editor @AutomatedTester has offered to lend us their expertise. Can we find 30 minutes on the schedule?
Yes. @jugglinmike Please suggest a time. Tuesday afternoon would be the easiest for us to move things around but other times may be possible.
Thanks, @jnurthen! How about 1:00 PM on Tuesday? (Really, any time will work for us)
@jugglinmike you got it. 1pm on Tuesday. @alice @cookiecrook not sure how this fits in with AOM but you might want to make sure you can attend.
@jnurthen is https://github.com/w3c/aria/issues/1001#issuecomment-529684283 happening? There's a lot happening at TPAC so it'd be good to know.
@annevk @domenic @foolip @sideshowbarker @mcking65 @zcorpan we have a meeting about web components scheduled at 2 on Monday. We could do 2.30? How long do you need?
How long do we get? 🙂 I think we could likely fill whatever time we get, but don't know if people have conflicts. How about 45 min?
The ARIA Working Group just discussed Long term planning for W3C explanitory resources related to ARIA and other web technologies
.
Since aria-braillereoledescription
is being tracked as a PR, I'm duplicating my comments from the open PR #924.
Comment 1 At TPAC we agreed that this should not require (and should actively discourage) using "characters from the Unicode Braille Patterns block" because, in almost all instances, the web author will not know what these should be, even if they are an expert in braille.
As the simplest example, the web author has no way of knowing whether the user reads uncontracted (Grade 1) or contracted (Grade 2) braille, so this attribute would be formatted as a non-braille unicode string. For example, the screen reader could translate aria-roledescription= "denomination" aria-brailleroledescription="den" into the user's preferred Grade 1 (⠙⠊⠝) or Grade 2 (⠙⠔) braille rendering.
Other examples author-encoded braille strings include when a user is fluent in multiple languages, but only fluent in one variant of braille. For example, a member of my team is fluent in reading, typing, and speaking English, but only reads braille using his native German braille table. VoiceOver can provide that to him, but a web author cannot.
Comment 2 We also agreed that it may be okay to allow unicode braille with sufficient warnings, and no examples of this usage. The only context I can think of where this is necessary is testing, where a user may be learning tactile braille through remote instruction. E.g. a student learning the differences between US English versus UEB, in Grade 1 or 2.
Comment 3 I am skeptical of suggesting the unicode braille block is necessary even in the case of Math polyfills like MathJax. For the same reasons listed above, the polyfill can't know whether the user prefers to read Math in Nemeth, UEB Math, or Computer Braille.
Current Agenda is at https://docs.google.com/spreadsheets/d/1eeq-xg0li2IKEIiyKsqhv-QOxArtbTV3m0OrG8ns-w4/edit?usp=sharing
Remote participation at https://www.w3.org/2017/08/telecon-info_aria-tpac
IRC channel
#aria
Please Add the F2FCandidate Label to any issue you want to add to TPAC Agenda.
Also please also add a comment in this issue with:
Once reviewed and added to the agenda we will remove the F2FCandidate label and replace with a F2F label.