Minutes: Low Vision Task Force 17 Jan 2019

https://www.w3.org/2019/01/17-lvtf-minutes.html

Attendees
PresentLaura, Jim, JohnRochford, AllanJ, jon_avila, SteveRepsherRegretsShawn
ChairJimScribeallanj
Contents

   - Topics <https://www.w3.org/2019/01/17-lvtf-minutes.html#agenda>
      1. Clarify 1.4.13
      https://lists.w3.org/Archives/Public/public-low-vision-a11y-tf/2019Jan/0011.html
      <https://www.w3.org/2019/01/17-lvtf-minutes.html#item01>
   - Summary of Action Items
   <https://www.w3.org/2019/01/17-lvtf-minutes.html#ActionSummary>
   - Summary of Resolutions
   <https://www.w3.org/2019/01/17-lvtf-minutes.html#ResolutionSummary>

------------------------------

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


-- 
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964