IBM ATAG Feedback

Hello,

Sorry this is slightly late, but I had one last issue I needed to follow up
on that caused a delay.  Thanks -


Principle A.1.

I am reading principle A and I find a very big hole in the specification.
Both ARIA and HTML5 specify how content is mapped to platform accessibility
service layers. If an author were to deliver "accessible" web content and
the user agent is not required to support accessibility API services for a
recognized platform or have built in AT that satisfy performance criteria
then how can the user agent be considered accessible? In other words,
despite an authors best effort the authoring tool fails to map the
information to the AT. A.1.1 only talks about the authoring tool chrome. I
am thinking of a browser plug-in like Policy tester. This is browser
specific and so the browser must support mapping the accessible web content
to the accessibility API.

So, to summarize, any browser component must be able to map the accessible
content in the authoring tool to the accessibility API. ... or does hidden
content refer to alt text. Hidden should be a glossary item to be clear.

What I think we need to do is say that if tool consists of web content then
you must also be operable in a browser that supports your content in the
form of accessibility services

A.1.2.1 - requires following user interface accessibility guidelines for
the platform. Should also accept international standards such as ISO
9241-171 or government standards such as Section 508.

A.1.2.2 - requires software to implement "communication with platform
accessibility services" - seems like this should be tied to the concept of
"programmatically determined" somehow. I'm not sure communicate "with"
platform accessibility services is the right concept. Isn't it more like
"using" accessibility services. And finally, it should just say
"accessibility services", not "platform accessibility services" to allow
for IAccessible2 implementations. Accessibility services are provided by
platforms most of the time but where platform accessibility services fall
short, other implementations that fill the gaps, such as IAccessible2,
should be allowed.

Guideline A.2.2
Why does A.2.2.1 include hidden elements? Please elaborate. Hidden content
is often dirty and not ready for consumption. Is it referring to alt text?
The solution is editorial but important and it is something we have had to
address in ARIA and HTML 5 too.

A.2.2.1 - "status messages being indicated" is very odd wording. I only
understood this when I read the implementing information. Now that I know
what it is, I suggest "information being conveyed by the status indicators"
instead.

A.3. - While I understand you are adapting this for WCAG 2 which requires
keyboard access we have a general problem in that most mobile browsers do
not respond to keyboard input. So, this is a gap in WCAG and ATAG. The 508
refresh punts this a bit in that it uses functional performance criteria as
a round about way to address the problem. I don't think that is a great
solution either. In short, we can't always assume a keyboard. We need
something on the order of allowing users to be able to control navigation
using device independent means. ... We need to work this now or in an ATAG
2.1 refresh but this is a significant gap for mobile. The good thing is
that there are not a lot of mobile web app authoring tools out there.
A.3.1., A.3.1.1, A.3.1.2 - these are already covered in WCAG which is
required by A.1.1.1. If these are for non-Web based authoring tools, then
they should be scoped to such tools.

A.3.1 - all of these are about keyboard operation which used to be the
"device independent" way of providing input. But now that we know we have
devices without keyboards that might have some other kind of device
independent input mechanism, should we go ahead and fix this even though
WCAG also has the problem?

A.3.1.3 - the example in the "implementing" material uses links as the
example. Suggest using landmarks instead of links.

A.3.2.2 - the Timing Adjustable requirement is already in WCAG so this is a
duplicate. If intended for non-web based UIs, then add an appropriate scope
statement.

A.3.2.2 - So, if timing is not adjustable you are saying that you don't
need to have one? I think you need a glossary item on what it means to have
a timing limit. e.g. a timeout, a refresh rate, a frame play rate (slowing
up and speeding out a video) etc. Again, I understand what you want but you
need a glossary item to be prescriptive.

A.3.4.1 - The navigate by structure states that you can navigate among
structural elements (or at least that is implied). However, Structure may
be defined through ARIA attributes such as landmarks. So this section
implies that structure is defined by element semantics alone and not the
attributes applied. Clarification is required.

A.3.6.1 - seems weird to include audio and haptic settings in "display
settings".

A.3.7.1 - Provide a glossary definition for in-market.
P
art B Comments

B.1.2.2 and B.1.2.3 - both of these need the phrase "if equivalent
mechanisms exist in the web content technology of the output" and the Note
that the success criteria only applies when the output technology is
"included" for conformance.

B.1.2.2 - So, when copying to the clipboard, each platform has standards
for formatted content in the clipboard. What happens if the those formats
do not support the accessibility information? ... In other words it *may*
not be possible.

B.4.1.1 - Are you sure you want authoring prompting turned on by default?
That is heavy weight. You do say *All*
B.2.3.1 - if the tool supports inserting a video, then this requirement
means the authoring tool has to provide a way to add/edit captions and
video descriptions?

B.2.3.2 - not sure "relevant sources" is testable. Sounds very subjective.

B.2.3.3 - why is this requirement limited to automatic repair of text
alternatives "after the end of an authoring session". Seems like it is also
relevant if the repair is being done during the authoring session.

B.2.5.1 - requires the pre-authored content selection mechanism to display
the accessibility status of the pre-authored content. But the example is a
clip art repository that displays the alt text associated with each clip
art object. "alt text" is accessibility information but it is not the
accessibility status.

B.3.1.1 - change "accessibility checking for that success criterion is
provided" to "accessibility checking or suggestions for manual checking for
that success criterion is provided"

B.4.1.3 - requires tools that do not comply with the requirements of Part B
to document the fact that they don't comply. There is no leverage to get a
tool developer to do this. If they document that they don't comply, they
still don't comply.


Sueann Nichols

Phone: (720) 396-6739 (t/l) 938-6739
ssnichol@us.ibm.com
IBM Human Ability & Accessibility Center
http://www.ibm.com/able