Fwd: Content on Hover or Focus comment

Hello Low Vision Task Force,

I am forwarding a message from Mike Gower. He would like opinions from
the TF on a Content on Hover or Focus comment.

Please chip in with your thoughts.

Kindest Regards,
Laura

-- Forwarded message --
From: Michael Gower <michael.gower@ca.ibm.com>
Date: Thu, 5 Apr 2018 18:01:31 +0000
Subject: Content on Hover or Focus comment
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: "Repsher, Stephen J" <stephen.j.repsher@boeing.com>

Hi Laura,
I've taken a stab at responding to a new comment on 1.4.13.
https://github.com/w3c/wcag21/issues/851#issuecomment-378942474

However, I could not actually think of any use cases which would break
 with the suggested rewording. I'd welcome any examples folks can come
up with of a component whose behaviour would either be altered or not
captured by the SC language with the changes suggested. Can you
surface to the LVTF? Otherwise I may extend to the whole list.

Steve, I know you're busy, but as the initial author, hoping you can
give this a look.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034


From:   Marc Johlic <marc.johlic@gmail.com>
To:     John Foliot <john.foliot@deque.com>
Cc:     Michael Cooper <cooper@w3.org>, "Abma, J.D. (Jake)"
<Jake.Abma@ing.com>, WCAG <w3c-wai-gl@w3.org>, Andrew Kirkpatrick
<akirkpat@adobe.com>
Date:   2018-04-05 08:13 AM
Subject:        Re: Problem with an implementation pass for Target Size



Hi John,

<jf> Paul Bowman came back with some interesting observations (that may,
or may not have surfaced a potential problem).   ...  Paul notes that when
he tried to apply the 44 px square requirement to all "Targets", that it
was messing up radio buttons and checkboxes, which meet the definition in
WCAG 2.0 for Targets:
  ...
[alt: partial screen capture showing check-boxes in the before (native)
and after (CSS'd to meet 44 X 44 px) states. Enlarging the check-boxes
also interferes with the visual rendering]</jf>

Do you know if Paul was applying any CSS to the checkboxes or radio
buttons prior to trying to meet 2.5.3?  If I'm interpreting that alt text
correctly, it looks like he was previously just using native checkboxes
and radio buttons.  If so, I believe they are exempt from 2.5.3's
requirements.  My understanding is that 2.5.3 only applies to form
inputs/controls if you've styled them (modified by the author).  From the
SC:

The size of the target for pointer inputs is at least 44 by 44 CSS pixels
except when:
Equivalent
The target is available through an equivalent link or control on the same
page that is at least 44 by 44 CSS pixels;
Inline
The target is in a sentence or block of text;
User Agent Control
The size of the target is determined by the user agent and is not modified
by the author.
Essential
A particular presentation of the target is essential to the information
being conveyed;


What do folks think?  Are unstyled/unmodified form inputs/controls exempt?


-Marc




On Wed, Apr 4, 2018 at 5:31 PM, John Foliot <john.foliot@deque.com> wrote:
Off the top, I think one of the problems is that the "Implementation
experience report" page for the Lego site is actually trying to accomplish
two things; both Target Size *AND* Orientation:
https://www.w3.org/WAI/GL/WCAG21/CR/implementation_experience?implementation_id=138

Can we confirm either of those items as passes? Do we need to split up
this report?

Additionally, I asked about getting this (SC 2.5.3 Requirement) into Deque
University using Alastairs CSS example, and Paul Bowman came back with
some interesting observations (that may, or may not have surfaced a
potential problem).

I was not fully invested in the Target Size SC evolution to the same
extent as others (including those in the Mobile TF), but Paul notes that
when he tried to apply the 44 px square requirement to all "Targets", that
it was messing up radio buttons and checkboxes, which meet the definition
in WCAG 2.0 for Targets:

"Target: region of the display that will accept a pointer action, such as
the interactive area of a user interface component"

... yet the related Understanding document for SC 2.5.3 makes no mention
of these types of targets/controls (yet lists other types):

"...The targets on a screen can have different purposes and uses, and this
Success Criterion specifies how each is to be handled..."

"Examples
Example 1: Buttons
Three buttons are on-screen and the touch target area of each button is 44
by 44 CSS pixels.
Example 2: Customizable
A mechnanism is provided to allow users to increase the target size of the
targets on the page to meet the minimum target dimensions.
Example 3: Equivalent target
Multiple targets are provided on the page that perform the same function.
One of the targets is 44 by 44 CSS pixels. The other targets do not have a
minimum touch target of 44 by 44 CSS pixels.
Example 4: Anchor Link
The target is an in-page link anchor and the target is less than 44px by
44px. Users can scroll the screen using browser functions so target size
does not need to be met.
Example 5: Text Link in a paragraph
Links within a paragraph of text have varying touch target dimensions.
Links within paragraphs of text do no need to meet the 44 by 44 CSS pixels
requirements.
Example 6: Text Link in a sentence
A text link that is in a sentence is excluded and does not need to meet
the 44 by 44 CSS pixel requirements. If the text link is the full
sentence, then the text link target touch area needs to meet the 44 x 44
CSS pixels.
Example 7: Footnote
A footnote link at the end of a sentence does not need to meet the 44 by
44 CSS pixels requirements. The footnote at the end of the sentence is
considered to be part of the sentence.
Example 8: Help icon
A help icon after a sentence does not need to meet the 44 by 44 CSS pixels
requirements. The icon at the end of the sentence is considered to be part
of the sentence.

..."
So at a minimum, some additional clarity around those two specific input
types (targets) is certainly warranted - i.e. do labels before or after
radio buttons and check boxes constitute "inline" content, exempt from
this requirement?
What about the design pattern where the label is followed by a carriage
return, and then the check-box or radio button is left justified to the
preceding label text (i.e. the label and the checkbox line-up to the left)
- is that also "inline"?
If yes to the above, we need to say so somewhere, as it is not obvious -
at least to me - one way or the other.


[alt: partial screen capture showing check-boxes in the before (native)
and after (CSS'd to meet 44 X 44 px) states. Enlarging the check-boxes
also interferes with the visual rendering]

JF


On Tue, Apr 3, 2018 at 5:53 PM, Michael Cooper <cooper@w3.org> wrote:
I went with a "majority rules" approach to recording the canonical result,
and did not evaluate the page myself. As such, Jake's perspective could be
right, but I'm not prepared to judge it myself. This is the reason,
though, we have a manual rather than an automated determination of the
canonical result, and if the consensus is it should be changed, we can
change it. It will mean we'll need to find another pass for target size.
Michael

On 03/04/2018 2:30 PM, Abma, J.D. (Jake) wrote:
Hi Michael / all,

In the call I heard that 2.5.3: Target Size was passed for the Lego site,
can anyone explain to me why?

https://www.w3.org/WAI/GL/WCAG21/CR/evaluate_central?implementation_id=138


My comment was: It fails smaller viewports where the next / previous
buttons  (in the canvas) are clearly less than 44X44 (check mobile or make
viewport small)

As far as I know Conformance is like this:

1.       Full pages: Conformance (and conformance level) is for full Web
page(s) only, and cannot be achieved if part of a Web page is excluded.
2.       Web page: a non-embedded resource obtained from a single URI
using HTTP plus any other resources that are used in the rendering or
intended to be rendered together with it by a user agent
a.       Note 1: Although any "other resources" would be rendered together
with the primary resource, they would not necessarily be rendered
simultaneously with each other.
b.      Note 2: For the purposes of conformance with these guidelines, a
resource must be "non-embedded" within the scope of conformance to be
considered a Web page.
3.       As we can see the Lego site only has 1 URI and an embedded canvas
element which needs to be fully accessible and doesn’t contain it’s own
URIs.

So we have a fail and not a pass.

It’s just like we have a page / 1 URI with a collapsible, or accordion, or
modal or whatever component / element and when you click on it, it opens
or reveals other content.
That complete component / widget / structure needs to be accessible
because it’s on the page, and not only the loading / beginning state and
not “not what’s in the collapsed content”.

It’s the same for the canvas, just as it is when you’ll get a keyboard
trap when clicking on the canvas buttons and you’re stuck we don’t say,
“well, if you don’t click on the canvas element than you’re save so we
pass it”.

So even though 4 people pass it I think they’re still wrong or please tell
me otherwise.

Regards,
Jake Abma

Accessibility Lead ING
Product owner at Team A11Y

ING Nederland / CIO / Omnichannel / Experience
ACT C.02.406, Bijlmerdreef 24
Postbus 1800, 1000 BV Amsterdam
0031 (0)6 - 25 27 52 46
jake.abma@ing.com

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the
intended recipient. If you are not the intended recipient, don't use or
disclose it in any way. Please let the sender know and delete the message
immediately.
-----------------------------------------------------------------

-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

-- End Forwarded message --
-- 
Laura L. Carlson

Received on Thursday, 5 April 2018 18:21:50 UTC