Re: WCAG Agenda May 24, 2016

On 5/23/2016 4:04 PM, Patrick H. Lauke wrote:
> Speaking of which - though probably jumping the gun here - my 
> quickfire thoughts on your points:
>
> 2.5.1:
>
> "iOS and Android both have a the concept of pass-through gestures. We 
> need to either explicitly allow this or disallow it as a way of 
> meeting these guidelines."
>
> pass-through gestures are, to me, the equivalent of "mouse keys" ... a 
> last resort, rather than an acceptable equivalent mechanism. So I'd 
> lean towards explicitly disallowing these.
> "Until HTML apps gain this ability there is really no way to meet this 
> requirement in complex applications without using pass-through gestures."
>
> Yes, by offering equivalent mechanisms to trigger the same actions 
> (i.e. the gestures are shortcuts, but traditional focusable and 
> actionable controls are also present - either all the time, or as an 
> optional setting). Basically, the same requirement as for keyboard 
> access.
Requiring all the functionality to be exposed visually is going to be 
way too distracting (and hard to use for a VO user to use as well) and I 
really don't want to have to go down the modes path again (I hate modes 
for a lot of reasons).
Imagine using iOS mail if there were icons for "Mark 
unread","Flag","More","Delete" after each message. Swiping through all 
of those icons would be really annoying. I would love to be able to 
replicate the native iOS experience in a web app with VO running but 
there doesn't seem to be any way to do so - and until there is 
passthrough gestures for things like these seem to be the best approach.
I do agree that these things need to be kept to the minimum and ideally 
used for non-essential functionality, or functionality that is available 
somewhere else (perhaps after a drill-down operation) but I'm not sure 
we can prohibit them completely without running the risk of making the 
UI worse for everybody.

>
> 2.5.4
>
> "If I have pinch(or double tap) zoom enabled then I should be able to 
> meet this at any zoom level."
>
> Once you zoom out, you can't really maintain the same touch target 
> size without the danger of overlapping targets. Also - speaking purely 
> from a web content perspective - as an author there's no way to detect 
> zoom level and to change padding or whatever on the fly, unless I'm 
> missing something.
That isn't what I meant by my statement.... it was my 2nd time filling 
out the survey so was a little frustrated by this time.
I was stating that, as the author, by allowing my user to zoom, the user 
can zoom in enough that they will be able to create big enough touch 
targets. If I don't disable zoom then I have allowed my user to be able 
to meet this requirement without having to do anything.
>
> And, as with the "large scale (text)" discussion...the sizing needed 
> to somehow be anchored on the ideal viewport / CSS reference pixel / 
> assumption that a device/OS/UA will choose appropriate physical sizing 
> for the reference pixel.
>
> "Requiring a 44px line spacing (which this would require) for any text 
> which might include links constrains the application design too much."
>
> Interestingly, the case of inline links didn't occur to me until 
> recently. the requirement doesn't necessarily mean line spacing has to 
> be potentially 44px - provided that links / controls aren't vertically 
> stacked (e.g. two links on two separate lines, one above the other), 
> then it should be fine to have static text/content above/below an 
> inline link, as long as the inline link has appropriate top/bottom 
> padding (which will effectively be over the text/content above/below it).
This doesn't sound practical really does it. How can I control where the 
links are in any arbitrary block of text on any device?
>
>
> On 23/05/2016 23:21, Patrick H. Lauke wrote:
>> It seems the results are recorded correctly, just not displayed in the
>> normal view. They do appear in
>> https://www.w3.org/2002/09/wbs/66524/2016-0509/results?view=compact
>> though (in a not very user friendly manner though)
>>
>> P
>>
>> On 23/05/2016 22:02, James Nurthen wrote:
>>> The mobile survey is borked. I recommend no one spends the time
>>> answering it until the chairs reply to say it is fixed.
>>>
>>> Regards,
>>>
>>> James
>>>
>>>
>>> On 5/23/2016 1:03 PM, Andrew Kirkpatrick wrote:
>>>>
>>>> The WCAG WG will be meeting on Tuesday, 24 May 2016 at 11AM Eastern
>>>> US (Length: up to 90 minutes)
>>>>
>>>>
>>>>
>>>> Attendance
>>>> survey:
>>>> <https://www.w3.org/2002/09/wbs/35422/WhenWCAG>https://www.w3.org/2002/09/wbs/35422/WhenWCAG 
>>>>
>>>>
>>>>
>>>> Scribe
>>>> list:
>>>> <https://www.w3.org/WAI/GL/wiki/Scribe_List>https://www.w3.org/WAI/GL/wiki/Scribe_List 
>>>>
>>>>
>>>>
>>>> IRC: irc.w3.org<<http://irc.w3.org>http://irc.w3.org> port: 6665
>>>> channel #wai-wcag
>>>>
>>>> Agenda:
>>>>
>>>>  1. TPAC Registration (https://www.w3.org/2016/09/TPAC/
>>>> <http://www.w3.org/2016/05/17-wai-wcag-minutes.html#item02>)
>>>>  2. Mobile TF
>>>>     survey: https://www.w3.org/2002/09/wbs/66524/2016-0509/ - please
>>>>     find some time to provide feedback
>>>>  3. https://www.w3.org/2002/09/wbs/35422/17thMay2016/ (Question 1 
>>>> only)
>>>>  4. Requirements for WCAG.next Success Criteria discussion (see
>>>>     Extension Requirements as starting point:
>>>>
>>>> https://rawgit.com/w3c/wcag/extensions/wcag20/extensions/requirements.html) 
>>>>
>>>>
>>>>
>>>>
>>>> To connect to the meeting:
>>>> Join WebEx meeting
>>>> (https://mit.webex.com/mit/j.php?MTID=m064eab3e5485b640231a7fe56dc4785c) 
>>>>
>>>> Meeting number:            642 418 206
>>>> Meeting password:         Find in the irc meeting room header if you
>>>> don’t know it
>>>>
>>>> or
>>>>
>>>> Join by phone
>>>> +1-617-324-0000 US Toll Number
>>>> Access code: 642 418 206
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> AWK
>>>>
>>>>
>>>>
>>>> Andrew Kirkpatrick
>>>>
>>>> Group Product Manager, Accessibility
>>>>
>>>> Adobe Systems
>>>>
>>>>
>>>>
>>>> <mailto:akirkpatrick@adobe.com>akirkpat@adobe.com
>>>>
>>>> <http://twitter.com/awkawk>http://twitter.com/awkawk
>>>>
>>>> <http://blogs.adobe.com/accessibility>http://blogs.adobe.com/accessibility 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Regards, James
>>>
>>> Oracle <http://www.oracle.com>
>>> James Nurthen | Principal Engineer, Accessibility
>>> Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987
>>> 1918 <tel:+1%20415%20987%201918> | Video:
>>> <sip:james.nurthen@oracle.com>james.nurthen@oracle.com
>>> Oracle Corporate Architecture
>>> 500 Oracle Parkway | Redwood Cty, CA 94065
>>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
>>> developing practices and products that help protect the environment
>>>
>>
>>
>
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment