Re: Problem with an implementation pass for Target Size

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