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

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

I have seen assistive technologies such as features in screen readers only work with the keyboard and not work correctly with the mouse.   Perhaps this is less likely on web pages – but I wonder if we need an exception for assistive technologies?  ATs may have special features that maybe it doesn’t make sense to make accessible with the mouse or perhaps not with the keyboard given the purpose of the AT.  The proposed Section 508 refresh has such an exception.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Monday, July 04, 2016 2:37 PM
To: Gregg Vanderheiden
Cc: Patrick H. Lauke; public-mobile-a11y-tf@w3.org
Subject: 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



CanAdapt Solutions Inc.
Tel:  613.235.4902

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

twitter.com/davidmacd<http://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<mailto: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<mailto: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


CanAdapt Solutions Inc.
Tel:  613.235.4902<tel:613.235.4902>
LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd<http://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<mailto: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<http://www.splintered.co.uk/> | https://github.com/patrickhlauke

http://flickr.com/photos/redux/ | http://redux.deviantart.com<http://redux.deviantart.com/>
twitter: @patrick_h_lauke | skype: patrick_h_lauke