W3C

- DRAFT -

ARIA Authoring Practices Task Force Telecon

04 Feb 2020

Agenda

Attendees

Present
Matt_King, carmacleod, jamesn, Jemma
Regrets
JonGunderson, MarkMcCarthy, SarahHigley, EvanYamanishi
Chair
Matt King
Scribe
jamesn

Contents


<scribe> scribe: jamesn

Warning about touch-based interoperability

https://github.com/w3c/aria-practices/wiki/February-4%2C-2020-Meeting#warning-about-touch-based-interoperability-gaps

mk: the warning text is "Users of touch-based assistive technologies may not be able to fully operate widgets that implement this pattern because APIs for capturing the necessary gestures and commands from assistive technologies are not yet available. Authors should fully test widgets using this pattern with assistive technologies before considering incorporation into production systems."

for patterns that it is impossible to make accessible in "mobile" browsers

jn: touch-based not mobile

mk: iOS increment is sent

jn: not talking about iOS
... think we should frame it correctly

mk: cannot make them accessible - put this warning on these patterns
... we know this is the case for slider
... are there any others
... are there any other patterns where tab or double tap are insufficient to make them work
... some others might be in that category according to 1186

https://github.com/w3c/aria-practices/pull/1186

jn: think we should see if can find menubar before adding a comment
... ios just doesn't have a tree
... would be a different issue. Not well supported but there is nothing inherently missing from making it supportable

mk: there are 2 spinbutton structures supported by aria
... 1 has them as child of composite element, one of them has them as siblings
... the spinbutton role is on the edit field
... can increment and decement by tapping the buttons
... the one in the toolbar may not work

jn: depends on what your def of work is

<Jemma> jn: none of spin buttons, increase/decrease would not work with iOS and macOS

<Jemma> jn:unless use system instruction how to operate those

<Jemma> jn: control+option+function may work but it is not standard way of operating it.

cm: we need someone who really knows iOS to test submenu and tree

mk: need to look at what our event handlers are doing
... I think your rationale for spinbutton is sound
... 2nd part reminds you to test

jn: 2 patterns I don't use are spinbutton and slider
... think they need new issues

mk: discussion of multi-select trees

action to put warning on spinbutton

<trackbot> Error finding 'to'. You can review and register nicknames at <https://www.w3.org/WAI/ARIA/track/users>.

More prominent note about use of examples in production

https://github.com/w3c/aria-practices/issues/1228

<Jemma> https://github.com/w3c/aria-practices/issues/1228#issuecomment-578671169

<Jemma> Complete proposal

<Jemma> Note: This is an illustrative example of one way of using certain ARIA attributes that conforms with the ARIA specification. There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices. So, testing any code that is based on this example with assistive technologies is essential before considering use in production systems. The ARIA-AT project plans to enhance this example with measurements of

<Jemma> assistive technology support for it by the end of 2020. Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heed the warning that No ARIA is better than Bad ARIA.

https://github.com/w3c/aria-practices/issues/1228#issuecomment-578671169

"Note: This is an illustrative example of one way of using certain ARIA attributes that conforms with the ARIA specification. There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices. So, testing any code that is based on this example with assistive technologies is essential before considering use in production systems. The ARIA-AT project plans to enhance this example with measurements

of assistive technology support for it by the end of 2020. Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heed the warning that No ARIA is better than Bad ARIA."

mk: proposed as summary detalils... heading in warning type style - critical note about use of this example

<Jemma> title can be "Critical Note about Use of This Example".

cm: would take out certain and attributes

<Jemma> +1

cm: would be nice to hear from Adrian

mk: can do it exactly how we want in a commnt
... have to manually add to any new examples
... if we were to add right before the H2 for example

<section>

<h2 id="ex_label">Example</h2>

https://github.com/w3c/aria-practices/blob/master/examples/checkbox/checkbox-1/checkbox-1.html

mk: in some examples there is a view before - be better if it were before

jn: right before the first section?

<carmacleod> or right before the first h2?

jemma: come up with a mock up
... I can do that

(discussing location)

<Jemma> brevity is the sister of talent ;-)

- This is an illustrative example of one way of using ARIA that conforms with the ARIA specification.

- There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices.

- Testing any code that is based on this example with assistive technologies is essential before considering use in production systems.

- The ARIA-AT project plans to enhance this example with measurements of assistive technology support for it by the end of 2020.

- Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heed the warning that No ARIA is better than Bad ARIA.

ARIA 1.2 combobox

mk: have a list of issues and want to know if they still exist in Jon's new version of the example

#1261: Focus problem when clicking on combobox dropdown button with mouse

#988: Combobox Example 3: List with Inline Autocomplete doesn't work with mouse

#983: ARIA 1.1 Combobox with Listbox Popup Examples - Mouse Hover style vs key board selection style

#982: ARIA 1.1 Combobox with Listbox Popup Examples - issue with onBlur

#785: Bug in examples: textbox "id" test for combobox/aria1.1pattern/listbox-combo.html

mk: all the bugs it fixes - want to make sure they are listed in the PR
... pulled from the list of bugs in the combobox project

785 & 982 & 983 came from the 1.1 combo but this was derived from that

mk: can have spectranaut look at one of them

one is a visual thing - maybe Zoƫ?

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/02/04 20:04:03 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: Matt_King, carmacleod, jamesn, Jemma
Present: Matt_King carmacleod jamesn Jemma
Regrets: JonGunderson MarkMcCarthy SarahHigley EvanYamanishi
Found Scribe: jamesn
Inferring ScribeNick: jamesn
Agenda: https://github.com/w3c/aria-practices/wiki/February-4%2C-2020-Meeting

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: 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]