See also: IRC log
<trackbot> Date: 19 October 2012
<Andi> chair: Mary_Jo_Mueller
<Andi> scribenick: MaryJo
<Andi> Functionality - 1.4.2 Audio Control https://www.w3.org/2002/09/wbs/55145/OCT112012/results
They reworked and edited the intent for 2.4.2, the link and link purpose SC's
<greggvanderheiden> Add the following paragraphs to the end of the INTENT sections for SC 2.4.2, 2.4.4 and 2.4.9 respectively. The link provided will take you to the full INTENT for the named SC:
<greggvanderheiden> SC 2.4.2
<greggvanderheiden> Add the following as a second paragraph:
<greggvanderheiden> In cases where the page is a document or a web application, the name of the document or web application would be sufficient to describe the purpose of the page. Note that it is not required to use the name of the document or web application; other things may also describe the purpose or the topic of the page.
<greggvanderheiden> Success Criteria 2.4.4 and 2.4.9 deal with the purpose of links, many of which are links to web pages. Here also, the name of a document or web application being linked to would be sufficient to describe the purpose of the link. Having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.
<greggvanderheiden> SC 2.4.4
<greggvanderheiden> Add the following paragraph as the second paragraph:
<greggvanderheiden> The text of, or associated with, the link is intended to describe the purpose of the link. In cases where the link takes one to a document or a web application, the name of the document or web application would be sufficient to describe the purpose of the link (which is to take you to the document or web application). Note that it is not required to use the name of the document or web application; other things may also describe the
<greggvanderheiden> purpose of the link.
<greggvanderheiden> Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application being presented on the page would be sufficient to describe the purpose of the page. Having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.
<greggvanderheiden> SC 2.4.9
<greggvanderheiden> Add the following paragraph as the second paragraph:
<greggvanderheiden> The text in the link is intended to describe the purpose of the link. In cases where the link takes one to a document or a web application, the name of the document or web application would be sufficient to describe the purpose of the link (which is to take you to the document or web application). Note that it is not required to use the name of the document or web application; other things may also describe the purpose of the link.
<greggvanderheiden> Success Criterion 2.4.2 deals with the titles of pages. Here also, the name of a document or web application being presented on the page would be sufficient to describe the purpose of the page. Having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.
When it comes to 2.4.2, we need review it to make sure in our guidance we say that the name of the application is fine.
<Andi> This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing “Web pages” with “non-embedded content or software”.
<Andi> Note: As described in the WCAG intent (above), the name of a software application or non-embedded content (e.g. document, media file, etc.) is a sufficient title.
<Andi> Note to Task Force: An amendment to WCAG 2.0 intent is being proposed at the October 11th meeting to address the concern that a document or application name is a suitable title that describes the purpose. It was confirmed that a name would in fact meet the requirements for title. This should in fact apply both to title and to links. They requested a proposal that would address both at the
<Andi> same time. A draft of that subsequent to the WCAG meeting and can be found at http://www.w3.org/WAI/GL/wiki/Purpose_and_doc/app_names.
https://www.w3.org/2002/09/wbs/55145/OCT172012/results#xq1
Some survey responders want additional examples.
<Andi> "For software and non-embeded content that use markup languages <del>, where </del> [IN SUCH A WAY THAT] the markup is separately exposed and available to assistive technology (AT) or to a user-selectable user agent, ... "
<greggvanderheiden> https://sites.google.com/site/wcag2ict/home/4-robust/41-maximize-compatibility-with-current-and-future-user-agents-including-assistive-technologies/411-parsing
AT interoperability could be done through the user agent DOM or by parsing the source (such as ODF for braille display).
<korn> Here is an updated bit of example text: "Examples of markup that is separately exposed and available to AT and to user agents include documents encoded in HTML, ODF, and OOXML. In these examples, the markup can be parsed entirely both by AT which may directly open the document, as well as is commonly accessed by AT using DOM APIs of user agents for these document."
If an end user is using a tool to create a document, the tool would automatically handle this SC without further action by the user.
<Andi> ACTION: Gregg to suggest to WCAG WG to add to 4.1.1 INTENT that authors using an editing tool should not have to worry about this. [recorded in http://www.w3.org/2012/10/19-wcag2ict-minutes.html#action01]
<trackbot> Created ACTION-72 - Suggest to WCAG WG to add to 4.1.1 INTENT that authors using an editing tool should not have to worry about this. [on Gregg Vanderheiden - due 2012-10-26].
<korn> 2nd example: "Examples of markup used internally for persistence of the software use interface that are never exposed to AT include XUL, GladeXML, and FXML. In these examples AT only interacts with the user interface of generated software."
<David> +1
Discussion about whether or not to show the whole substitution of the SC either with or without the intent and notes. The intent is important, but it may be more readable if our guidance is put directly under the SC and have the intent after that.
<korn> +1
<BBailey> +1 on the idea to have intent collapsible
<Andi> ACTION: Andi to schedule agenda topic to talk about overall organization & presentation - intent before our guidance, intent after our guidance, intent links to WCAG, additional version of the guidance doc with just the substitutions [recorded in http://www.w3.org/2012/10/19-wcag2ict-minutes.html#action02]
<trackbot> Created ACTION-73 - Schedule agenda topic to talk about overall organization & presentation - intent before our guidance, intent after our guidance, intent links to WCAG, additional version of the guidance doc with just the substitutions [on Andi Snow-Weaver - due 2012-10-26].
RESOLUTION: Accept proposal #6 for 4.1.1 as updated in the meeting.
<Andi> ACTION: Andi to put process resolution about grammatical edits on next agenda [recorded in http://www.w3.org/2012/10/19-wcag2ict-minutes.html#action03]
<trackbot> Created ACTION-74 - Put process resolution about grammatical edits on next agenda [on Andi Snow-Weaver - due 2012-10-26].
<Pierce> +q
https://www.w3.org/2002/09/wbs/55145/OCT172012/results#xq2
<Andi> the suggestion I made to Alex that he is referring to is to scope this to "UI Controls that change the presentation of the UI"
This SC is hard to create good guidance in the non-web world. We don't want to have our guidance expand the meaning of the SC.
<Pierce> +q
There are 3 options to deal with this: (1) Say we can't achieve consensus (2) Push boundaries of definition of a navigation mechanism (3) say this SC doesn't apply in some contexts, such as software.
<Pierce> +q
<Pierce> -q
<Pierce> +q
We could make a statement that this is not an issue in software, wouldn't normally be included in guidelines for software.
If we go with options to the WCAG working group, it may cause our schedule to be at risk since it could take multiple meetings with the working group to resolve. Suggest whatever we can capture from our discussions for now, we just do that.
Assertion that if we have to define terms, change the intent, etc. to make an SC apply to software then it really doesn't need to be mapped to a requirement for software.
<Pierce> +1 David
<korn> It isn't just URLs. See http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html and look at the first example: " Examples of Success Criterion 3.2.3 A consistently located control A search field is the last item on every Web page in a site. users can quickly locate the search function."
<Pierce> Keep it to the definition of URL
<Pierce> -1 David
The non-normative intent of this SC scopes in controls.
<Pierce> +q
Proposal #9 was created by Andi to make some clarifications for non-embedded content and to say that for software we don't have additional guidance on applying to software.
We may have reached consensus on the difficulties with this SC, even though we haven't reach consensus on the guidance.
Since WCAG has the notion of 'Set of web pages', this is what creates many of the issues for applying to software. Sofware is so different inside, requiring these SC to apply inside of software applications causes problems.
Suggested way to get this to closure - that this makes sense in documents, but not so much to software for 'sets of software'.
A 'set of software' almost never occurs.
Some would prefer to say this SC doesn't apply rather than say we didn't reach consensus, if we were allowed to do so.
If we can't say it doesn't apply, readers of the document would have to digest the information we do provide for the SC and come to their own conclusion that the SC doesn't really apply to software.
<Pierce> +q
We could say that the way this SC is written by WCAG, that it would be interpreted to a 'set of software', explain the concept of 'set of software', and say that this doesn't happen very often.
<Zakim> Bruce_Bailey, you wanted to say that “does not apply” is better than “no consensus” but can we task the “does not apply” camp to distinguish that case from Gregg’s
The problems could even be worse with a set of software. Example of administrator application that is part of a set of software and you wouldn't necessarily even want the navigational mechanisms to be consistent.
<Pierce> +q
<korn> "Dear WGAG WG: We could not find a way to define precisely what 'navigation mechanisms' are for software. We would like to be able to say one of a combination of either "doesn't not apply to software", or "in software, this can apply to UI controls whether or not they are 'navigation mechanisms'. Otherwise, we feel all we will be able to say is 'couldn't reach consensus'"
We got to the proposal #9 that we have by expanding the SC, but the group hasn't accepted the proposal.
There could be software that mimics a Web interface. In this case this SC would apply.
The issue is what are the boundaries of a navigation mechanism and what a set of software is.
We do know what UI controls are and what a software application is, so it makes more sense to adjust the SC to these concepts.
However, this is an expansion of the scope of the SC.
<David> +1 on Peter
It is hard for developers to know when this SC should be applied, but even harder for testers to figure out when there is a failure because the SC should be applied.
Some software changes the order of elements in the navigational mechanism depending on the role of the user, which is something intentional to make the software usability better for that role.
Requiring this SC in those cases would make the software less usable for certain roles.
<Pierce> I do not agree that these are good principles to apply to SW, so defining a set of SW is not helpful from my perspective
These are not necessarily good principles to apply to sets of software.
There are not bright lines where this SC applies and where it doesn't apply.
<greggvanderheiden> which is not the same as saying it doesn’t apply
<greggvanderheiden> just that it is hard to say when ti does or doesn’t it
<korn> Gregg: it doesn't apply as a rule.
Suggestion to capture the instances of issues with applying this SC reliably and that is actually counter to many software principles.
<greggvanderheiden> one can't say that it applies in some places but doesn’t always apply so it doesn't apply
<greggvanderheiden> '
Perhaps we should propose some language of where we are on the remaining SC along with opposing opinions.
<korn> Gregg: we can construct a software UI that looks exactly like a web page that doesn't use HTML, and therefore observe that it could apply there.
<Andi> ACTION: Peter to work with Gregg to draft summary of our positions on applying 2.4.1, 2.4.5, and 3.2.3 to software [recorded in http://www.w3.org/2012/10/19-wcag2ict-minutes.html#action04]
<trackbot> Created ACTION-75 - Work with Gregg to draft summary of our positions on applying 2.4.1, 2.4.5, and 3.2.3 to software [on Peter Korn - due 2012-10-26].
<korn> But that doesn't mean it can be made to apply generally to software.
Need to return to handling the comments on our draft.
Survey on write-up of issues with the remaining unconsensed SC to be taken to the WCAG working group to receive futher guidance.