Close with comment: Addressed by the requirement that delivery units can be parsed unambiguously, with no ambiguities in the resulting data structure, and by the three techniques now (as of the 15 December 2005 Editor's draft) listed as sufficient.
Close with comment: This concern is addressed by new wording for GL 4.1 and its success criteria, and by the concept of baseline. Please review the baseline document to see if it meets the need you identified.
Close with comment: The primary concern of this issue is compatibility. Baseline and the latest resolutions related guidelines 4.1 and 4.2 should address this concern. Please review the baseline document to see if it meets the need you identified.
Close with comment: This is addressed by baseline and the 4.2 SC requiring accessible alternatives for inaccessible content and controls that are outside the baseline (e.g., if Java isn't in the baseline). Please review the baseline document to see if it meets the need you identified.
Close with the comment: addressed by edits to examples, specifically to "Understanding WCAG 2.0: Success Criterion 4.2.3" which also links to IBM resources in the "related resources" section.
The new language does not create these exceptions. Jason raised the same issue in his response to the new draft, with a little twist-- that since we don't say that the grammar has to be public, someone could create a delivery unit using a proprietary, unpublished format that wouldn't be accessible to any AT. This objection would be met by baseline and by 4.2 SC requirements about accessible alternatives for inaccessible content outside the baseline. If the new technology is included in the baseline, then it would have to meet all L1 SC to claim conformance.
Close with comment: This is addressed by baseline and the 4.2 SC requiring accessible alternatives for inaccessible content and controls that are outside the baseline (e.g., if a custom DTD isn't in the baseline). Please review the baseline document to see if it meets the need you identified.
Close with comment The issue of workarounds for current technologies is addressed by the baseline and Guideline 4.2. Please review baseline document to see if it meets the need you identified.
OBE
Close with comment: Issues of validity are addressed by GL 4.1.1 as it appears in the 23 November 2005 Working Draft, and by adding validation and conformance to the list of sufficient techniques in Understanding WCAG 2.0 (as approved on 01 December 2005).
"Using technologies according to specification is very important for adaptive technologies. Most technologies have some form of validator so there is no excuse for not using technologies according to spec. It should be a level 1 criteria to use technologies according to spec."
Close with comment: Addressed by new wording, by baseline and by definition of "programmatically determined" which explicitly includes AT. Please review baseline document to see if it meets the need you identified.
It seems like this the responsibility of user agents rather than content. [Comment on "4.2 L1 SC 5: The states and values of content that can be changed via the user interface can also be changed programmatically."
Close with comment: Typically (especially with HTML), state and value is responsibility of the user agent. However, with java and with some examples from the DHTML roadmap, the author needs to use accessibility apis (e.g., Java, dynamic content roadmap) to ensure that states and values can be changed by the assistive technology.
OBE - no longer using the term.
Assistive technology needs to be able to determine these attributes even when they are not changing. [Comment on "4.2 L1 SC 6 (now 4.1.5): Changes to content, structure, selection, focus, attributes, values, state, and relationships within the content can be programmatically determined."]
Close with comment: There are two separate success criteria 4.1.2 [The role, state, and value can be programmatically determined for every user interface component in the Web content that accepts input from the user or changes dynamically in response to user input or external events.] and 4.1.5.
When content does change (via interaction with scripts), the AT needs to be notified of changes and receive the updated values. 4.1.5 ensures that changes show up in the DOM so that the AT has access to that information. If it's static, it's covered by 4.1.2.
Replace the phrase "changed programmatically" with "programmatically changed" throughout the document, and add a definition for the phrase. The document already defines and uses "programmatically determined", "programmatically identified", and "programmatically located", so using "programmatically changed" would be more consistent, readily identifiable, and appear with the related phrases in the alphabetically-arranged glossary. [Comment on "4.2 L1 SC 5 (now 4.1.4): The states and values of content that can be changed via the user interface can also be changed programmatically."]
Propose the following rewording of the SC and definition, plus remove the editorial note
4.1.4 The content and properties of user interface elements in the Web content that can be changed via the user interface can also be programmatically changed. (Level 1)
Note: Some examples of standardized properties that typically can be changed by the user interface include its value, whether it is currently selected, and whether it currently has the focus.
Programmatically changed - can be changed by assistive technologies that support the technologies in the chosen baseline.
Discussion and related issues that are addressed by this proposal
The editorial note related to this SC reads, "The working group is still considering whether this criterion should be included and, if so, at what level." We propose that this editorial note should be removed and that this SC should remain because it synchronizes well with the following two UAAG checkpoints:
UAAG 6.3 #2
If the user can modify the state or value of a piece of non-HTML/XML content through the user interface (e.g., by checking a box or editing a text area), allow programmatic read access to the current state or value, and allow the same degree of write access programmatically as is available through the user interface.
If the user can modify the state or value of a piece of HTML or XML content through the user interface (e.g., by checking a box or editing a text area), allow programmatic read access to the current state or value, and allow the same degree of write access programmatically as is available through the user interface.
Another issue that came up in our discussions for this proposal is the possible redundancy of WCAG 2.0 success criterion 4.1.4 with WCAG 2.0 SC 2.1.1. However, we determined that 4.1.4 differs from 2.1.1 in that 2.1.1 is about all functionality of the content and 4.1.4 is specifically about changing the content and properties of UI elements.
Another question that we discussed is the difference between 4.1.4 and 4.1.2 and we propose that 4.1.4 differs from 4.1.2 in that 4.1.4 is about programmatic write access and 4.1.2 is about programmatic read access.
This should also apply to output-only controls (and content) that are only updated when the page is rendered. [Comment on "4.2 L1 SC 3 (4.1.2): The role, state, and value can be programmatically determined ."]
for every user interface component of the web content that accepts input from the user or changes dynamically in response to user input or external events, the role, state, and value can be programmatically determined.
current: 4.1.2 The role, state, and value can be programmatically determined for every user user interface component in the Web content that accepts input from the user or changes dynamically in response to user input or external events
Suggest we close with one of the following proposed changes:
This should apply to controls that display information as well as those that take input. For example, take a page where a static text field displays the label "Name:" and to its right a static text field displays the value "George"; in this case the former text control is presenting the label of the latter, and this relationship is no less important to the viewer than it would be if the user could directly edit the displayed value. [Comment on "4.2 L1 SC 4 (now 4.1.3): The label of each user interface control that accepts input from the user can be programmatically determined and is explicitly associated with the control."]
current: 4.1.3 The label of each user interface control in the Web content that accepts input from the user can be programmatically determined and is explicitly associated with the control.
Suggest we close with one of the following proposed changes: 4.1.3 For each user interface control in the content, the label can be programmatically determined and is explicitly associated with the control.
rationale: cutting out the phrase "that accepts input from the user" because it should apply to all controls not just those that accept input.