Re: Should we require all functionality to be operable with pointer?

>that would require that all content have an on-screen keyboard.

hmmm... I guess we don't mean "all" functionality, but rather, any
functionality that should use a pointer, should be accessible to pointer...
functionality of typing is not a good use of mouse... unless you *are using
on on screen keyboard* (already covered in WCAG)

Patrick's point is also a good one, that most dev's make stuff accessible
to a mouse anyway, so the question arises... how big is the problem for
people in the real world?

Anybody, know of any "real world" accessibility issues where something was
not available to a mouse/pointer, because of some mistake by a developer
that needs correcting for accessibility reasons in WCAG? I can't think of
anything in my experience.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Mon, Jul 4, 2016 at 1:27 PM, Gregg Vanderheiden <
gregg@raisingthefloor.org> wrote:

> Grin
>
> that would require that all content have an on-screen keyboard.
>
> the only way for an author to ensure that everything I operable with only
> a pointer — would be for them to include and on-screen keyboard on every
> page that has text input — unless we are going to declare that there is no
> platform anywhere that does not include an on-screen keyboard.      Might
> be true - don’t know.
>
> But remember what you are asking of an AUTHOR   when you require something
> be there that not all platforms may have.
>
> Maybe a page that runs on a browser with voice for input?   and no on
> screen keyboard?      If there is one — then an AUTHOR needs to detect it
> and make all pages have an on screen keyboard as part of the page.
>
> that kind of thing.
>
> tricky bit
>
> *gregg*
>
> On Jul 4, 2016, at 12:08 PM, David MacDonald <david100@sympatico.ca>
> wrote:
>
> Perhaps its as easy as proposing a new Success Criteria... How about this?
>
>     All functionality <https://www.w3.org/TR/WCAG20/#functiondef> of the
> content is operable with a pointer.
>
> With our definition of pointer including mouse, touch, pen, as per the
> mobile calls.
>
> Cheers,
> David MacDonald
>
>
> *Can**Adapt* *Solutions Inc.*
> Tel:  613.235.4902
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd
> GitHub <https://github.com/DavidMacDonald>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Mon, Jul 4, 2016 at 8:05 AM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 04/07/2016 12:55, David MacDonald wrote:
>>
>>>
>>> http://www.davidmacd.com/blog/should-WCAG-require-all-functionality-by-mouse.html
>>>
>>
>> Coincidentally, I've said as much in the past.
>>
>> https://twitter.com/patrick_h_lauke/status/602418310903365632
>>
>> WCAG assumes that things will work with a mouse (because of course that's
>> how developers build it), so that is tacitly taken as the status quo which
>> needs to be expanded to then also cover keyboard.
>>
>> So fundamentally yes, I believe an explicit SC that requires
>> functionality/content to be accessible to users with a mouse/other types of
>> pointer is needed. This also dovetails with how we expanded our proposed
>> touch/activation target SC to cover not just touch targets, but general
>> pointer targets too.
>>
>> Exceptions would include controlled environments where there is no
>> mouse/pointer, e.g. a point-of-sales or ATM that only has a (physical or
>> on-screen) keyboard.
>>
>> (Incidentally, this really makes me wish the TFs were set up more along
>> the lines of "Input TF", since that's what this really falls under - so the
>> "mobile" moniker for this TF is a bit loose).
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>>
>
>