RE: WCAG extension review by Rich

I have been reading it all as well and it struck me that we have made it all very focussed on the English language in particular with the writing style and layout.  Do we need to mention impact of localisation somewhere - text direction, use of conditional tenses, active/passive and double negatives etc that may not apply to some languages.

Best wishes
E.A.

Mrs E.A. Draffan
WAIS, ECS , University of Southampton
Mobile +44 (0)7976 289103
http://access.ecs.soton.ac.uk<http://access.ecs.soton.ac.uk/>
UK AAATE rep http://www.aaate.net/

http://www.emptech.info<http://www.emptech.info/>

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: 18 January 2016 18:46
To: public-cognitive-a11y-tf@w3.org
Subject: WCAG extension review by Rich

I reviewed the WCAG proposal:

https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Proposal_for_WCAG


I made some edits to the WIKI but here are my comments.


Here are my comments

Under WCAG 1.3
·        We need to do more than just provide symbols on key content. We need to have key content appear in the same location throughout the application (Location is key for seniors) and it is just as important as the symbol. e.g. the help icon should appear in the same location across the web application.
·        It mentions standardized techniques but we need to support standardized semantics
·        We also need to support standardized user preferences.

Under WCAG 2.2
·        20 hour timeout? That would represent a security issue. I don't think that will fly. It is too long.
·        It says timed events are not used but if you are in an assessment environment this is problematic.

Under WCAG 3.1 Clear Structure
·        So, this talks about headings but this should include the ability to find landmark regions. The regions should be clearly identified (boundaries, labels, etc.) even in high contrast mode.
·        The criteria for meeting the flat design issue may be addressed by an OS setting. For example, iOS has a feature to render button shapes in place of the flat design basic outline of the button


WCAG 3.1 Interactive controls ...
·        We need to determine the bounds of controls - even in a high contrast setting. Otherwise, the user can't find them or determine what they are for.

WCAG 3.1 Instructions, navigation, and non trivial information ...
·        Regarding, reducing ambiguities, we should not limit this to clarifying content. A service could be employed to replace ambiguities with text that is implicit.  A key part of our strategy needs to include third party services that do these things and how to determine that they have been applied.
·        We need vehicles for testing a lot of this like testing for ambiguities. This will require accessibility test tool innovation.
·        for links and buttons it talks about conveying clear purpose. What about image buttons? I think the title text (tooltip) would need to be clear and it would need to be visible on a hover.
·        We need guidance on what represents a clear phrase. This could be subjective.
·        We are going to need to define standardized word lists per language.

WCAG 3.1: When there is a barrier between the content and the user that requires additional cognitive function an alternative is provided that does not require additional cognitive function
·        Authentication to systems: The net of this is we need to require a form of authentication that does ot require the user to remember anything other than to bring a key token device. This has cross-disability advantages. This is problematic for a voice response system however.
·        We need to make this section simpler and more easy to get the gist of it.
·        for IoT of things  I think an URC with a passcode in a "wallet" that could be verified would help.I made a number of edits to this section. I understand the intent but it was too hard for someone to parse.
·        How is this content different from any other disability? "When an author makes design choices that mean people who could have used their content now can not, that content is not accessible. " Why is it here?
·        I redefined cognitive function in the text as it was too hard to parse.
WCAG  3.2: A predictable design is used that includes enabling the following within the site

  *   We need to create a definition for "Consistent Layout". Too much will be left to the interpretation. Symbols and common interactive features must look the same and appear in the same location so it is much easier to find and associate its function.
  *   Links must generally look the same as they would on the web. For example, I have a number of IBM products that continue to create links with underlines. It is very annoying.
  *   We must ensure consistent paths in the software to get at the same information or functionality.
WCAG 3.3: Applications should continuously provide easily-recognizable rapid feedback of success or failure with every action with an option for spoken feedback.

  *   We need a requirement that this be personalized. What is familiar to some is not familiar to others. For example, if some one is used to Windows and you show Mac symbols or android symbols it is confusing.
  *   Some of this feedback should be optional. Some may be annoyed by it because it slows them down.
  *   Another technique for feedback should be the integration of reminders such as in active calendar where you remind someone that a meeting is going to begin in a half hour.
  *   Another technique would be to indicate when a breadcrumb changes in a breadcrumb list.
  *   We neeed to require WebSpeech support in all browsers as a requirement to support coga (multi-modal reinforcement). Not all browsers are there yet. There needs to be browser requirements going forward. This needs to be part of the Roadmap.
  *   This section is definitely going to require personalization. Not everyone will like these techniques
WCAG 3.3: Support is provided that help users understand the content, that includes:

  *   This section mentions APIs for synchronization. I think this needs to be part of the gap analysis for coga. Potentially, this could involve standardized extensions to the Accessibility API work. The presence of these in a web page would help with conformance checking as well.
  *   I think the use of charts and graphs do not always lead to understanding. Some of them are very hard to understand. Frankly, it would be better to ask the system what you want in many instances.
  *   We should consider optional user assistance on line as a vehicle to help users.
  *   We need to define test criteria. ... We need to be able to test for a clear font.
  *   I am not sure that breaking forms into 4X4 are desired by all users.
WCAG 3.3: Support is provided that help users complete and check their tasks that includes

  *   The known techniques is a big issue with respect to knowing when we are done and how to test this entire section. This will be an area that we will get huge pushback if we cannot articulate this. Otherwise, this could put companies at risk.
  *   I think we need to define different types of input controls and define a way to indicate what format they are and to determine if the format matches the acceptable formats.
  *   Also, the text says to represent the temperature in the locale but what if the person is traveling to the locale and does not understand the centrigrade or farenheit measurements? This may need to be customizable.
  *   The ONLY way to address this is to scope what it needs  to meet this very concisely. I got the impression from reading this that people were just throwing examples out. We may not have gotten all of the critical techniques. We need to be sure.
  *   THIS SECTION OBVIATES A NEED FOR A WCAG REQUIREMENT SOLELY FOCUSED ON PERSONALIZATION.
WCAG 3.3: Provide mechanisms that help the user focus and to restore context if attention is lost.


  *   I added the following: "Reminders of broader context issues in the broader scope of a product must be provided (if you have a calendar/mail program you should provide a feature that could notify the user of an impending meeting or to dos"
  *   I think it will be important to categorize types of applications to help with this. For example, any calendar or event planner should come with reminder capability. We all suffer from attention deficit issues and we need the ability to help us establish context of what needs to be done during the day.
  *   We should render an indicator of what the the current item (usually last chosen or activated item) of contexts on the page. For example an aria navigation section or bread crumb may have a current item: "aria-current" that should be indicated just like visual focus and it should be rendered consistently based on user preferences.
  *   For COGA should context sensitive help be AAA? Wouldn't it be AA?

Details on new SC and potential techniques:

We need to make sure we clearly define how to test these and how testing can be automated. The thing that I see is the biggest issue is the shear volume of requirements. We will get huge pushback if we cannot reduce the amount of manual testing and I suspect that will include more scoping.

To a large extent we are trying to boil an ocean here.

Items where WCAG 2.0 SC Levels should change.
No comments at this time.

General Requirement: WCAG compliant content must support a personalization mechanism based on user needs, device capabilities, and environmental conditions. This goes beyond coga but if we are going to get this to be bought into it is critical. What is good for one user is not for another.







Rich Schwerdtfeger