RE: Moving personlization forward - wording suggestion



From: Michael Pluke [mailto:Mike.Pluke@castle-consult.com]
Sent: Tuesday, July 4, 2017 11:04 AM


Programmatically determinable contextual information is available for regions, common form elements, common navigation elements and common interactive controls.

This does not include “context sensitive help” from the current wording – is this deliberate or an omission?

I still think that there may be the following problems:


  *   Don’t some people have a problem with the words “contextual information”. What qualifies as contextual information and are there existing standards or published schema that define the appropriate semantics?
[Jason] In particular, it’s necessary to define what it entails that is not already addressed by 1.3.1 and 4.1.2. Part of the proposal appears to be that the purpose or function of the UI control should be identified in metadata, extending beyond the “role” information that typically only specifies the general type of component involved. However, it’s unclear what level of specificity would be needed to satisfy the proposal. Without mandating a specific taxonomy, which would be too restrictive, it’s hard to specify precisely what is wanted here. The closest I can arrive at is that whatever metadata format is used should be mapped to symbol systems that can be understood by certain populations with cognitive disabilities. However, presumably (and I may be wrong on this point), different symbol sets express different concepts, and more symbol systems can readily be created.
The same UI component can be described or characterized in different ways. What should qualify for purposes of WCAG as sufficient identification of the purpose/function of a control? If we had a definition that we knew was robust and reliable, we would be well on the way to a viable proposal.

  *   Then there is the word “common”. This will clearly need to be precisely defined. Without a definition it could mean:

     *   commonly used across websites – a tester would have no way of knowing the frequency of use different types of interactive controls for example.
     *   Commonly used within a website – which would need to be backed by testing of all pages or author provided statistics of which are the most commonly used types.
     *   Or something else …
[Jason] I agree this is a problem. The first option has the additional disadvantage that what is common can change over time completely independently of the actions of the page author – trends on the Web at large can alter what is “common” according to that conception. As a result, what conforms today might not conform five years later due to changes in the frequency of various controls on the Web generally, even if the individual Web page or Web site remains unaltered. I don’t think this is an acceptable outcome for conformance.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Wednesday, 5 July 2017 14:46:52 UTC