W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2015

RE: More on not using Screen Magnification as an example

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Fri, 24 Apr 2015 13:05:52 +0000
To: Wayne Dick <waynedick@knowbility.org>, WAI Interest Group <w3c-wai-ig@w3.org>
Message-ID: <BY2PR03MB272E95AFA500460D450AB0C9BEC0@BY2PR03MB272.namprd03.prod.outlook.com>
[Wayne wrote]

>  Screen magnification works just as well on a bitmap as
 it does on a WCAG 2.0 Level AAA document with perfect ARIA.

While I am not a screen magnification developer – I believe this may be an over simplification.  There are many aspects of assisting with magnification that you cannot do with an image.  For example, focus tracking can be very important. Tracking of programmatic focus is used to move the magnified view.  Words can be programmatically highlighted in the magnified view of a web page, focus enhancement can be layered on top of focus and caret tracking to assist users in finding the caret and/or focused control.

> I have not experienced any
evidence of screen magnification vendors using ARIA, but maybe
someone knows more on this.

Screen magnifiers such as ZoomText pay attention to the aria-activedescendant attribute or it’s API implementation to track focus on controls such as toolbars, tabs, and menus where this attribute can be used.


Ø  .   Screen magnification has
no place in a document about APIs that support assistive
technology. CCTVs and magnifying glasses are  just as relevant
screen magnifiers in this context.
Screen magnification software can track changes in content in parts of the screen and it can be used to only magnify part of the screen.  It can track focus and it can be combined and communicate with other assistive technology such as a screen readers (e.g. MAGic and JAWS).  Screen magnifiers are most definitely watching WinEvents such as obj_focus, value_changed, system_alert, and other programmatic events sent from the application operating system.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>

703-637-8957 (o)
Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup> | Twitter<http://twitter.com/#%21/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

From: Wayne Dick [mailto:waynedick@knowbility.org]
Sent: Thursday, April 23, 2015 7:49 PM
To: WAI Interest Group
Subject: More on not using Screen Magnification as an example

 The reason screen magnification does not belong in the new
 Accessibility API Mappings 1.1 document is because the primary
 functions of screen magnification and the accessibility APIs are
 disjoint. Screen magnification works just as well on a bitmap as
 it does on a WCAG 2.0 Level AAA document with perfect ARIA.

I am fully aware that modern screen magnification software uses
some features of the DOM supported by WCAG 2.0. These are mostly
used to enable vertical navigation.  I have not experienced any
evidence of screen magnification vendors using ARIA, but maybe
someone knows more on this.

The main point is this. The primary work of a screen magnifier
is enlargement with very intelligent curve smoothing.  While
this requires really smart programming the same effect can be
achieved with a closed circuit TV.   Screen magnification has
no place in a document about APIs that support assistive
technology. CCTVs and magnifying glasses are  just as relevant
screen magnifiers in this context.
In fact, magnfying glasses and closed circuit TV is just as relevant as screen magnification within the entire context of WCAG.  WCAG is unnecessary for screen magnification to work.

Received on Friday, 24 April 2015 13:06:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 May 2017 01:54:15 UTC