Issues the chairs overlooked in their review of the canvas accessibility API proposal for Issue 131

I read the chairs decision yet the chairs never read the details as to what
and why the changes were made. Consequently, some facts were overlooked in
the decision and because the objection by Ian never raised these points in
his objection I felt no need to raise them in my objection. Here are the
issues I see were overlooked.

1. In reading the chairs chairs decision to keep canDrawCustom it did not
regard a point made in my change proposal which is that if the author sets
canDrawCustom to true and the operating system has not specified out a
focus ring is to be drawn, that drawing is turned over to the author. When
an author draws a focus ring manually it does not, in fact, drive a
magnifier. Not all operating systems provide special focus ring drawing
settings and not all low vision users specify how focus rings are supposed
to be drawn. This breaks accessibility for low vision users as arbitrary
drawing does not drive magnifiers. This is highlighted in the details
section bullet 2 of
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection

Now, in our version of the proposal the author is responsible for creating
the drawing path and all the styling attributes for that drawing path to
create the focus ring. If the operating system has provided as setting for
how the drawing path is to be drawn then those setting would be honored -
no different from the current text. Even if the author has set
canDrawCustom as a property the current text states that the user agent
should draw the focus ring based on the system. So, the cleanest solution
would be to eliminate canDrawCustom altogether and provide a single call to
draw the focus ring based on the system settings if available or based on
the drawing path styling chosen by the author otherwise. Either way, the
drawFocusRing must be used to draw a focus ring to drive magnification.

Authors should be forced to follow system settings as these are set by a
user based out of personal preference. Personal preferences are set for a
variety of reasons, the most serious being that the user simply cannot use
the application because of an impairment. To address this issue government
procurement standards, such as 508, require applications to support system
font and color settings. If your application does not comply you fail
purchasing requirements. It should be noted that, in our proposal, if no
system setting has been set for focus ring then the drawFocusRing simply
draws along the path as the author specified while at the same time
updating the magnifier based on the focus ring.

2. The chairs decision to keep the existing drawFocusRing creates a problem
in that the function can not be used to drive a magnifier as it draws an
unneeded focus ring. The function also provides no guidance as to how the
user agent is to use this information to drive a magnifier. For the same
reason it does not allow an author to use the X, Y position to drive a
magnifier during the selection process. Our proposal does and explains how
a user agent is to drive a magnifier.

For these reasons, why is the existing drawFocusRing function a better
solution for driving a magnifer when moving a caret and the user's
selection position?

3. The chairs ignored bullet 1 of the details section of the Change
Proposal which was to address a request from magnifier vendors to have the
with and height of the caret or selection position to better position the
magnifier at high magnification levels:
"moved to setting of the caret and selection position to a separate API

from DrawFocusRing to a separate API called setCaretSelectionPos that takes

x, y, w, h parameters to define the caret selection position being reported

to the browser to pass on the the platform accessibility API services. The

additional width and height of the caret will allow user agents to better

assist screen magnifiers in positioning the zoom position at large

magnification levels with combined with the semantic information provided

by the corresponding element passed from fallback content."

The current specification for focus ring does not address this.

I would ask the chairs to reconsider their decision on our change proposal
for Issue 131 in light of this new information.

Thank you,

Rich Schwerdtfeger
CTO Accessibility Software Group