W3C

- DRAFT -

Low Vision Accessibility Task Force Teleconference

17 Jan 2019

Attendees

Present
Laura, Jim, JohnRochford, AllanJ, jon_avila, SteveRepsher
Regrets
Shawn
Chair
Jim
Scribe
allanj

Contents


<laura> No

<steverep> Meeting today? Could someone paste the link with the Webex info?

<laura> yes

<laura> It is in the agenda: https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2019Jan/0012.html

<scribe> scribe: allanj

Clarify 1.4.13 https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2019Jan/0011.html

ja: if user causes content to appear on focus, is there a requirement that the user can use the mouse to review the popup content.

<steverep> Thanks Laura

ja: Mgower did some testing with zoomtext... keyboard and mouse worked.
... question - What is the expected behavior?

sr: why wouldn't it stay persistent. how would you program it so it wouldn't stay.

<laura> This is WCAG Issue 582: https://github.com/w3c/wcag/issues/582

ja: keyboard trigger separate from mouse trigger.
... should be able to hit ESC from anywhere to dismisss ig

sr: if keyboard focus is still present, content should stay present until keyboard focus moves or content is dismissed.

<laura> SC text says; ”If pointer hover can trigger the additional content, then the pointer can be moved over the additional content".

ja: depends how you read the SC.

sr: if you trigger something by mouse, it should stay if you move the keyboard focus.

ja: is related to 2.5.6 concurrent input mechanisms.
... what is group intention.

laura: don't think it was our intention.

jim: thinks that focus move should be the dismissal action. hover should not cause popup info to disappear.

sr: agree with Jim. The SC says content should stay up until it is dismissed.

<laura> The SC text says “The additional content remains visible until the hover or focus trigger is removed(…).”

ja: Persistent -- hover or focus trigger
... hover or focus is removed from the triggering element and the additional content.

sr: yes. if menu, keyboard focus moves to sub menu, and main menu disappears then it is a failure. (perhaps 3.2.2)

ja: developer displays menu with hover, mouse moves off of trigger, menu disappears
... if I focus a menu with keyboard, then move hover to open a different menu. does the keyboard menu stay open?
... things are persistent until it is dismissed by the user

sr: can create a complicated example. don't want to encourage bad development. need a practical example.
... tracking 2 different actions. when ESC is triggered additional content is closed.

Steve will respond to the issue. if changes are necessary - it should be in the understanding.

jim: discussion of AT and keyboard/mouse interaction.

Understanding - https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

ja: have 2 buttons, additional content appears below button, if I use AT cursor key to move to content, and focus changes then AT may cause content to disappear.

jim: perhaps we need another example to explain the hover and keyboard focus. need real world examples.

<scribe> ACTION: Steve to create additions to 1.4.13 Understanding with Jim

<trackbot> Error finding 'Steve'. You can review and register nicknames at <https://www.w3.org/WAI/GL/low-vision-a11y-tf/track/users>.

<scribe> ACTION: Steverep to create additions to 1.4.13 Understanding with Jim

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

sr: concurrent input mechanism - author taking active measures to restrict user actions. None of 1.4.13 is inherent in browser/OS, author is not restricting. Author is creating interactions.

<laura> 2.5.6 Concurrent Input Mechanisms: Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.

Jim: @@need to put the caveat about 2.5.6 in the 1.4.13 Understanding document

close item 2

open item 2

<laura> Low Vision User Needs Coverage Google Sheet:https://docs.google.com/spreadsheets/d/1gwp30K0OJ46mtjKCwo__cCIHn6mgTl-fvn2A_ADzwEc/edit#gid=0

<laura> https://docs.google.com/spreadsheets/d/1gwp30K0OJ46mtjKCwo__cCIHn6mgTl-fvn2A_ADzwEc/edit#gid=0

sr: keyboard focus should take priority. its ok to have focused menu, and a hover menu - when something is clicked, then focus is moved and focus menu should disappear.

jim will find examples and send to Steve.

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: Steve to create additions to 1.4.13 Understanding with Jim
[NEW] ACTION: Steverep to create additions to 1.4.13 Understanding with Jim
 

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: 2019/01/17 17:07:51 $

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)

Succeeded: s/nin the agenda/in the agenda/
Default Present: Laura, Jim, JohnRochford, AllanJ, jon_avila, SteveRepsher
Present: Laura Jim JohnRochford AllanJ jon_avila SteveRepsher
Regrets: Shawn
Found Scribe: allanj
Inferring ScribeNick: AllanJ
Found Date: 17 Jan 2019
People with action items: steve steverep

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]