See also: IRC log
<Jan> doh its not...its 28943
<Jan> jeanne, is this correct? I will send out individual emails!
<jeanne> Go with individual then. I don't see an error on the list and all the systeam are in Calif.
<jeanne> Let me try first and see if mine go through
<jeanne> I dont' see any errors or blocked message in list maintenance.
<Jan> I just send you a doc that maybe you can post...
<Jan> plus also can you post the updated agenda I cc'd you on?
<jeanne> scribe: jeanne
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0045.html
Jan reviews email of proposal [http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0045.html]
GP: If you review on a 3rd party for checking, e.g. Dreamweaver no longer has a built-in checker, so Adobe can file a claim saying that anyone of these 6 3rd party checkers can be used.
AL: Microsoft is reluctant to endorse any 3rd party product, so Microsoft would not want to list a built-in checker.
JR: But since Microsoft doesn't use 3rd party products, it won't be an issue
JT: It is a dependency, not an endorsement
AL: But we don't list any screenreaders in our VPATs, for example, because we can't do that - even if it is dependency, it gets interpreted as an endorsement, so we don't do it.
JS: COuldn't we allow a category of accessibility checker, for example?
JT: But how we then ensure the accessibility checker was ATAG compliant? We need names.
AL: It is important to make a
distinction between the complete product and saying a product
can do part of ATAG, but not all
... the example of the Accessibility Toolbar that does not
meeting part A and most of part B.
JR: AT the last F2F, we discussed
having a conformance of ATAG-Ready, which is for limited
products, which just states it doesn't break anything.
... This is why we took a workflow approach in the first place.
We have a conditional "if your users are not allowed to break
WCAG, you don't need a checker".
AL: If you have a clear yes/no, then you have a more robust ATAG.
JR: 3rd party checking and repair, Microsoft doesn't want to endorse. But some tools need to have a 3rd party checker. Is there a conditional that would allow us to bridge the lack?
JT: the initial issue is the collection of tools. The other issue is the option to point to a dependency on an external product, which other companies have expressed a desire to do.
GP: ATAG complaince CAN address a collection of tools.
<W3C> Another example using a WYSIWYG editor in a web based CMS.
JT: there is a reality that there are mashups. THere are very few tools that are monolithic and are not dependent on other tools. We can address the confusion by making clear the bounds of the compliance statement. But we cannot ignore that authoring tools, like other tools, are becoming more dependent on other tools.
AL: Let's say you have 3 or 4 tools in an authoring environment and each of the tools can have its own claim.
JT: They could not claim unless they were a collection.
AL: You are assuming that someone
has to meet everything before the author is going to
proceed.
... if I know I need to do X, Y, and Z, I will collect the
tools I know.
... each part will have a chunk fulfilled by each tool.
JT: If the authoring function were within the tool, but the checking situation means that the authoring tool may not include.
AL: then we need the authoring tool to have built-in or aftermarket.
AC: We need a way from a
web-based authoring system to use Tiny-MCE, for instance,
... If a set of tools doesn't cover all of ATAG, then it
shouldn't be open to have a full conformance statement? ]
JR: ... ATAG is written for a system of authoring tools and features to produce accessible content. We don't want to have to tell 3rd parties what they have to do.
AL: then ATAG is not requiring a tool to do anything, but get 3rd party products to do all the work.
JT: So are you saying that 3rd party conformance should be moved to conditional statements in the success criteria.
AL: I am saying that we need to
be more creative.
... we need rethinking that would come to a better
solution.
JT: What are the functionalities that can be pointed to 3rd parties for? checking and repair, certainly, but are there any others?
GP: Checking and repair is the
primary one. Other than PDF, we are not in the validation
business. It's not a one-size-fits-all. We define a workflow,
and are fine with recommending other solutions.
... market forces come to bear, 3rd party vendors come to us
and ask to be on our list of recommended tools.
JT: If it is only checking and repair, then making it conditional to the SC makes sense.
AC: If Tiny MCE has it's own
conformance claim, so that the CMS doesn't have to claim it for
it.
... where you include 3rd party tools can introduce its own
accessibility claims.
... transformation is another area for 3rd party tools.
JR: we need to have some kind of statement of "plays nicely with others"
GP: But a checking tool requires you to go back and repair.
AL: I think we will have a
complex conformance statement. Even with today's version of
ATAG, they would have to be addressed in the conformance
statement.
... If the conformance claim makes it clear what it does and
what it doesn't do, it makes it easier for the Systems
Integrator to assemble the proper collection of tools.
JT: We embed it into the success criteria for Checking & Repair, you can do it by built-in C&R or by 3rd party C&R.
AL: This is brainstorming that is pretty close to my train of thought.
AC: This is more general than checking and repair. Some CMS do not include a WYSIWYG editor, a mashup interface creator will want to reocmmend tools to create an accessible interface.
<Jan> scribe: Jan
AC: Just wondering if in terms of
conformance...not the SCs themselves...but how we ask them to
perform...
... It's the in situ installation that would be asked to
conform
... Not necessarily the tool itself
JT: The question becomes...does combination compliance statement adress purchaser need to have a tool they can use and that creates accessible content for end users
AC: Yes, tool could say
positively what it does do
... And what it doesn't try to meet
JT: So if thats the first level who's responsible for full ATAG level
<jeanne> scribe: jeanne
AC: If you have an author using Dreamweaver, then you may want to point them to another tool, but in many CMS systems, the people who install or integrate things that assemble the tool collections, not the author.
JR: That's part of hte ATAG ready --- they play nicely with others -- [publically availble claims] and then those making an ATAG claim can refer to those tools.
JT: Do we need ATAG-ready if it only covers a small number of functions.
JR: It is confusing if someone who doesn't have a checker claims it.
AC: We would take responsible for our system, but it becomes more complex when an aggregator or integrator is making a claim for a configuration of products.
AL: It is a common scenario to have a mixture of technologies, so you could have a whole complex matrix of technologies to be used to create a conformance claim.
<Jan> +1 to Jeanne's idea
<Zakim> jeanne, you wanted to suggest we make a list of use cases.
JT: It would also be useful to
test ATAG conformance claim where a developer could make a
claim on their own product, and a second conformance option
where an integrator can make a claim on a collection of
tools.
... b) we make use cases to challenge this proposal.
AL: I have additional questions
on MS2: the value chain of authoring tools - would the firmware
on the scanner be a part of ATAG? How does one know that one is
creating web content these days.
... if I send a FB message, and you use FB app on phone, it is
not web content, but if you use the FB web page, it is?
<W3C> AC: I have a feeling that it can be solvedin the conformance area rather than re-jigging success criteria, but happy to come up with use-cases
JT: We will move on to the next issue with MS2 and work on the use cases and scenario proposals for later.
<Jan> ACTION: All to send in conformance use cases related to the multi-tool issue [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action01]
<trackbot> Sorry, couldn't find user - All
<scribe> ACTION: jan to work with ALL to send in conformance use cases related to the multi-tool issue [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action02]
<trackbot> Created ACTION-361 - Work with ALL to send in conformance use cases related to the multi-tool issue [on Jan Richards - due 2011-11-07].
<Jan> ACTION: JR to model what it looks like to move 3rd-party dpendency out of conformance claim and into the SCs (checking and repair) - so that compliance statemtn is simpler [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action03]
<trackbot> Created ACTION-362 - Model what it looks like to move 3rd-party dpendency out of conformance claim and into the SCs (checking and repair) - so that compliance statemtn is simpler [on Jan Richards - due 2011-11-07].
JT: it would be good to model to take the dependencies out of the compliance
AL: WCAG did not draw a specific
boundary around what is web content.
... if you use Word or Powerpoint, you see an HTML file, not
the docx or ppt file you would see if you used the desktop
client.
... for authors, it is very different, it is the same process,
it is the recipient who determines if it is web content or
not.
JR: then isn't it up to the tool to decide to use ATAG? The docx document may not have to meet ATAG because it doesn't have to, but then the author says "Save as HTML" and then the output isn't accessible because the tool ddin't put it in when it was being created.
AL: I don't know what will end up
being a web agent. I am not saying that we don't do anything
when it isn't intended for web content, because we do.
... like a fax can be turned into web content.
JT: We are saying that it is only for web content. You don't need to make a statement for non-web content.
AL: for Word, for example, the primary function is to create a docx file. If someone chooses to do the conversion, we say you transform at your risk.
JR: What if tomorrow FIrefox and Safari announce they will support docx format natively?
AL: that is important to look at, and we will identify it as potentially risky.
JT: If we pursue that further, that transformation needs to conform to ATAG, and therefore, to support that claim, Word would need to have the ATAG features to support that transformation.
AL: We aren't going to change the product, just because it has a transformation function. We will probably add a disclaimer that the author transforms at its own risk.
JT: It is stated corporate policy that Microsoft wants to create accessible document.
AL: I like to compartmentalize
specific products. MS has a long history of creating products
and content that is accessible.
... Word is not a web development tool. I need to draw a
line.
... we have to flesh this out with WCAG working
group.
<scribe> ACTION: jeanne to work with Jutta to coordinate with the WCAG WG on the definition of web content and set boundaries of what is included as web content. [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action04]
<trackbot> Created ACTION-363 - Work with Jutta to coordinate with the WCAG WG on the definition of web content and set boundaries of what is included as web content. [on Jeanne F Spellman - due 2011-11-07].
UNKNOWN_SPEAKER: because ATAG is being discussed as legal requirements, we have to remove ambiguity. Otherwise Microsoft has to pay many engineers to explain these ambiguities in court.
<Jan> MS3: Most touch screen devices do not use the keyboard for navigation. Keyboard is only used for text input. The current definition of keyboard interface does not work with the corresponding SC within the context of touch screen devices. Also, please refresh the term PDA. It is no longer in use today.
<Jan> OLD: An interface used by software to obtain keystroke input. A keyboard interface can allow keystroke input even if particular devices do not contain a conventional keyboard (e.g., a touch screen PDA can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected). Keyboard-operated mouse emulators, such as...
<Jan> ...MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.
<Jan> NEW: Keyboard Interface: An interface used by software to obtain keystroke input. A keyboard interface can allow keystroke input even if particular devices do not contain a conventional keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected). Keyboard-operated mo
<Jan> use emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.
AL: what it it only has keyboard as text and no keyboard navigation?
JR: Both iOS and Android support keyboard navigation
AL: The paradigm of keyboard as people with mobility impairments has changed.
JR: the ability to move focus without activation
AL: Keyboard interface is no longer the only way for people with blind or mobility impairment to move. This is a change from when WCAG was written.
<Jan> A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
JR: Do we change the SC to be a more updated term and is there a more updated term?
JT: can we define the functionality in a less technology specific way.
AC: there are still things that map to keyboard access on a very basic level that we need to support.
JR: Could this be addressed by a note? We mean that pointer or touch independent navigation mechinisms.
AL: I think it could be done by changing the success criteria.
<Zakim> jeanne, you wanted to say that UAAG is talking about it as supporting keyboard as a most universal input mechanism
AL: not the physical keyboard,
but the concept of keyboard.
... voice input experts strongly support mapping to
keyboard.
<Jan> ACTION: JR to To draft a Note 3 to clarify A.3.1.1 Keyboard Access (Minimum) for keyboard-less devices [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action05]
<trackbot> Created ACTION-364 - Draft a Note 3 to clarify A.3.1.1 Keyboard Access (Minimum) for keyboard-less devices [on Jan Richards - due 2011-11-07].
adjourning until 2:15 EST
<Jan> Taking break...back at 2:15pm ET
<Greg> Greg is back
IPcaller is Jutta
<scribe> scribenick: W3C
<jeanne> scribe: Alastair
<Jan> Proposal at: http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0046.html
SA: Our biggest issue is that the
person who owns the IP should make the claims.
... don't need to create separate mechanisms than those that
already exist, they aren't fundamental to ATAG, they should be
consistent across the W3C recommendations.
Jan: We've covered the multi-tool
aspect earlier (generally).
... NB: WCAG doesn't look at who makes the claim, but in
general we should follow WCAG's lead.
... Looking at the WCAG conformance claims section, we can drop
the first paragraph (web content specific).
... 1-3 are the same, but 4th point (authoring tool
information) is different, we need to add that.
... We add platforms on which it is evaluated, important
because tools can use UA features.
... Platform on which the platform is evaluated.
SA: Should we specifiy the tools to test with?
Jan: We don't specify that.
... It is from the author point of view
AL: If it is for windows (say), does it matter which version?
Jan: will change to the platforms
you are making part of this claim (or similar)
... we have a different perspective on the listing, we are
specific about the technology the tool is claiming for.
... We have a not-applicable for some success criteria.
SA: Why should some things be NA?
Can't people just say that
... Shouldn't we also have comments for No? Why not?
Jan: Someone trying to police a claim, sometimes it isn't obvious, when it isn't obvious, that creates a big question.
AC: Some SC can only be yes/no, some can be NA
SA: From a corproate perspective, if we make a claim, these are conscious answers, so why don't you want more information about 'no'?
AL: going back to collections of tools, think about individual tools. A tool might do 5 applicable success criteria because it is small and descrete.
From an envronment where people are putting together a solution, they need to know which tool does what, and be able to fill the holes.
AL: it is necessary to distinguish yes/no/na. The default answer with NA would be because it does not meet the if/then statement
Jan: Shall we remove that whole point (7), and move it down, out of required?
AL: Do we want to differentiate yes/no/na? Is it in the conformance claim?
Jan: In the draft, it includes something but happy to move down to optional components.
AL: A lot of the specific tools will have a lot of NAs.
AL; Comments should be optional but encouraged?
SA: We ahve to be able to evaluate tool individually, but when doing that, these claims may not have some critical info in order to assess the aggregation.
??: Integrators could be on top of the tool's statements
SA: People putting statements
together should be able to gather these usefully, and the
solutions are very dynamically created.
... People quickly put these tools together, there isn't
necessarily one assessment
... Someone making a decision about a solution should be able
to get the info for the whole picture.
... All we can do, at the individual tool level, create an
assessment of what the conformance is, and encourage people to
be detailed.
??: So all should be commentable?
SA: We should strongly encourage that comments are detailed around non-compliance / applicability.
<Jan> 7. Result for each of the success criteria (Yes, No, Not Applicable)
Jan: Remove the part about explanation for each NA, and propose we replace that with (the above)
<Jan> An explanation of the success criteria results (Yes, No, Not Applicable) where this may not be obvious.
<Jan> An explanation of the success criteria results (Yes, No, Not Applicable).
Jan: I'll put it in an appendices
at the end.
... removing several things that are WCAG 2 specific
... Added items on editing views.
... Do we need a machine readable version?
People can do that if they want to.
Jan: I'll replace the old
conformance claim section with the new documented
version.
... WCAG has two other sub-sections we've removed. 1st: 3rd
party content, and languages, neither of which are particularly
relevent to us.
AL: Quite straightforward, we
aren't too clear about what automating means, which affects a
few SCs.
... alternative way would be to determine what isn't
automated.
<Jan> content generation (content authoring, content editing)
<Jan> The act of specifying the web content to be rendered, played or executed by user agents (also may be referred to as "content authoring" or "content editing"). This may refer to information perceived by end users or to instructions for the user agents. Content may be author generated or automatically generated:
<Jan> author generated content: When authors are fully responsible for the web content (e.g., typing markup into a source editing-view, writing captions for audio).
<Jan> automatically generated content: When programming by the authoring tool developer is responsible for the web content (e.g., applying a template, automatically correcting markup errors).
<Jan> In some cases, responsibility for content generation is shared. For example, an author requests an interactive object be placed on their page (e.g., a photo album), the authoring tool applies a template, but the template requires input from the author to be complete.
Jan: Thought that almost everything was at some time specified by a person (developer), by an if/then statement. E.g. what a browser does when seeing HTML seems automatic.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0049.html
Jan: Take Alex's poitn about
people propose:
... it adds a couple of categories for content generation.
AL: heading in right direction, might need some word-smithing.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0048.html
Jan: NB: Some items are separated
into A/AA/AAA
... We have the (WCAG) to indicate the levels.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0048.html
AC: Are they mutually exclusive?
Jan: pretty much, they are sort of in order of amount of change though, so the recoding is the most change.
AL: Not sure when some
'accessibility information' can be lost?
... where can we draw a boundary around it?
Jan: We could go through WCAG and
call-out what we are talking about?
... But where would that be used, the implementation doc?
AL: That's quite important, when you transform something it's easy to loose things, if you have a specific list it helps.
Jan: Should that be informative
or normative.
... I'll pull those things out, and we can decide if it's
needed.
<Jan> ACTION: JR to Build table of Accessible Information (WCAG) [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action06]
<trackbot> Created ACTION-365 - Build table of Accessible Information (WCAG) [on Jan Richards - due 2011-11-07].
Greg: Assuming it guides you into accessible authoring, should it then pop-up if you can't check this?
Jan: May not be dialogues,
greg: What is meant by notify?
Jan: Could be in the help.
Jutta: Original intent: inform authors about consequences of decisions, such that they know what they need to do to create accessible content.
Jan: It would be great, but tools
do a lot of things, and we don't want accessibility to be
integrated rather than in your face. Assume a tool has HTML
& SVG, but they don't have accessibility features for
SVG.
... If the tool lets people know that the HTML version will be
more accessible, then a notification in the help (or something)
should be enough.
Greg: That would be fine, it's the notion of error messages at the time.
AC: 'option of being informed' implies interface aspect.
<Jan> B.4.1.X Feature Availability Information: If the authoring tool supports production of any web content technologies for publishing for which the authoring tool does not provide support for the production of accessible content, then the authoring tool notifies authors when support for the production of accessible content is not available. [Level AA]
<Jan> Note: This requirement concerns the presence or absence of support features such as accessibility checkers. It does not concern any intrinsic property of web content technologies.
Greg: Authoring tool notifies...
Jan: that could be repetative
<Jan> B.4.1.X Feature Availability Information: If the authoring tool supports production of any web content technologies for publishing for which the authoring tool does not provide support for the production of accessible content, then this documented. [Level AA] Note: This requirement concerns the presence or absence of support features such as accessibility checkers. It does not concern any...
<Jan> ...intrinsic property of web content technologies.
Greg: that implies intelligent notifications.
<Jan> \
Jan: will replace with 'this is documented'
<Jan> Resolution: All agree with " B.4.1.X Feature Availability Information: If the authoring tool supports production of any web content technologies for publishing for which the authoring tool does not provide support for the production of accessible content, then this documented. [Level AA] Note: This requirement concerns the presence or absence of support features such as accessibility...
<Jan> ...checkers. It does not concern any intrinsic property of web content technologies."
Agree that these are guidelines, not interoperability specifications.
<Jan> Resolution: All "WCAG 2.0 and UAAG 2.0 also do not use RFC words. The reason for this is that these are guidelines and not interoperability specifications."
<Jan> Resolution: All agree to ""Programmatically" is a defined term that is borrowed from WCAG 2.0. This requirement deals with passing text alternative through from the content to assistive technologies."
Agree with response.
Jutta: We also want to allow for keyboard access that is not as generic as the OS level, it is specific to the application.
<Jan> There is an accessibility advantage allowing users to customize keyboard access (e.g. to create keyboard strategies for functions and features unique to the application). This is not absolutely necessary for accessibility, which is why it is listed as AAA.
Jutta: Especially for the complex tools.
<Jan> Resolution: All "There is an accessibility advantage allowing users to customize keyboard access (e.g. to create keyboard strategies for functions and features unique to the application). This is not absolutely necessary for accessibility, which is why it is listed as AAA."
<Jan> Right, and it should be available in the user interface, not just by going to a long list of keyboard commands in the help documentation.
Jan: agree with the comment, the wording could be formalised for ATAG.
<Jan> Reworded: A.3.1.6 Present Keyboard Commands: Provide a way for authors to determine the keyboard commands associated with authoring tool user interface components.
<Jan> Resolution: All ok with "Reworded: A.3.1.6 Present Keyboard Commands: Provide a way for authors to determine the keyboard commands associated with authoring tool user interface components."
Jan: this is the ability to navigate code or markup based on their relationship
Jutta: point is to provide another wayto navigate around the interface
Jan: uncomplied (raw?) code rather than rendered views.
<Jan> AUWG: The point here is to provide another quick way of moving around the authoring tool user interface, at a AAA level. We are refering to the programmatic relationships that exist in program code and markup (e.g., the ability to find where a variable is defined), not just to structural markup-type features.
Jutta: do we have a definition of that version of programmatic?
Jan: it is pretty clear in the SC, which has examples.
<Jan> Resolution: All accept: "AUWG: The point here is to provide another quick way of moving around the authoring tool user interface, at a AAA level. We are refering to the programmatic relationships that exist in program code and markup (e.g., the ability to find where a variable is defined), not just to structural markup-type features."
AL: Making it allowable that they conflict?
AC: Appears to be a get-out clause, not sure the context of custom-settings is clear
Jutta: It should use CSS style inheritance, that was the intent
AL: Not sure how you fail this SC?
Jan: If you have custom settings
it's ok, but if not, you should respect the user
settings.
... e.g. high-contrast mode, at level AA that should be
respected.
Jeanne: In general, it is like the CSS cascade or other examples where the local override the generic. Rational is because you inherit the generic unless you specific something else.
Jan: If a tool provides settings
to change background/text colour, by having those settings it
can be taken as conflicting with the users settings.
... should apply platform setting unless the authors
overrides.
AC: How about: "unless the author has chosen custom display or control settings"
<Jan> The authoring tool respects changes in platform display and control settings unless they conflict with the display and control settings of the authoring tool chosen by the author.
<jeanne> +1
<Jan> ACTION: JR to Produce a proposal around "A363 The authoring tool respects changes in platform display and control settings unless they conflict with the display and control settings of the authoring tool chosen by the author." [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action07]
<trackbot> Created ACTION-366 - Produce a proposal around "A363 The authoring tool respects changes in platform display and control settings unless they conflict with the display and control settings of the authoring tool chosen by the author." [on Jan Richards - due 2011-11-07].
<Jan> If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple sets of settings.
<Jan> If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple profiles of settings.
<Jan> If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple profiles of these settings.
<Jan> If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple sets of settings.
<Jan> A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple sets of settings.
<jeanne> multiple groups of settings?
<Jan> Resolution: "A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple sets of settings."
<Jan> A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple configurations of settings.
AC: "If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading the settings."
<Jan> Resolution: Replace with "A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple configurations of settings."
Jutta: reponse is to say we've proposed the new wording.
<Jan> JT: Response to TL12 that we are proposing a rewording as follows to address the ambiguity
<Jan> In-Market User Agent: The preview renders content using a user agent that is in in-market
<Jan> In-Market User Agent: The preview renders content using a user agent that is in-market
<Jan> (a) In-Market User Agent: The preview renders content using a user agent that is in-market.
<Jan> Resolution: all agree to "(a) In-Market User Agent: The preview renders content using a user agent that is in-market."
Jutta: is that a definition or re-wording of the SC
AC: "for interface features available to authors"
<Jan> The authoring tool includes documentation for user interface features that are available to authors.
Jan: let's propose this to Alex, as he started the issue.
<jeanne> +1
<Jan> ACTION: JR to To propose "A.4.2.2 Document All Features: The authoring tool includes documentation for user interface features that are available to authors." [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action08]
<trackbot> Created ACTION-367 - Propose "A.4.2.2 Document All Features: The authoring tool includes documentation for user interface features that are available to authors." [on Jan Richards - due 2011-11-07].
<Jan> ACTION: JR to Remove ":" in B.2.2.2 [recorded in http://www.w3.org/2011/10/31-au-minutes.html#action09]
<trackbot> Created ACTION-368 - Remove ":" in B.2.2.2 [on Jan Richards - due 2011-11-07].
Jan: TL16 is editorial, let's move on.
Jutta: see the response to TL1
<Jan> Resolution: "AUWG: It is best left to the the developer. For example, if there are only a few accessible choices, it might be better to call them out.. "
<Jan> Resolution: All ok with "AUWG: We are giving a rationale rather than a hard claim. That said, alt use is higher than some less prominent accessibility attributes (e.g., longdesc)."
Jeanne: Let's put an example in the implementation doc, and say that in the reponse.
<Jan> Informing does not have to take the form of a dialog box, this will be made more clear in the implmenting document.
<Jan> Resolution: "AUWG: Informing does not have to take the form of a dialog box, this will be made more clear in the implmenting document."
<Jan> AUWG: Authors will vary in the degree to which they heed any guidance from their authoring tool. The requirement is on authoring tools, not users of authoring tools.
<Jan> Resolution: "AUWG: Authors will vary in the degree to which they heed any guidance from their authoring tool. The requirement is on authoring tools, not users of authoring tools."
<Jan> source views: The content is presented in unrendered form (e.g., plain text editors); or
<Jan> AUWG: We have not been able to find a better term. "raw" and "underlying" don't seem to fit the text editor context. The fact that browsers render things seems to lend support to "unrendered".
Greg: Formated vs formated?
??: Doesn't get to the source aspect though.
<Jan> AUWG: We have not been able to find a better term. The fact that browsers render things seems to lend support to the use of "unrendered".
<Jan> Resolution: All ok with "AUWG: We have not been able to find a better term. The fact that browsers render things seems to lend support to the use of "unrendered"."
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: jeanne Inferring ScribeNick: jeanne Found Scribe: Jan Inferring ScribeNick: Jan Found Scribe: jeanne Inferring ScribeNick: jeanne Found ScribeNick: W3C Found Scribe: Alastair Scribes: jeanne, Jan, Alastair ScribeNicks: W3C, jeanne, Jan Present: Jan Jeanne Cherie Jutta Alastair Greg Alex Tim_Boland Sueann Agenda: http://lists.w3.org/Archives/Public/w3c-wai-au/2011OctDec/0051.html Got date from IRC log name: 31 Oct 2011 Guessing minutes URL: http://www.w3.org/2011/10/31-au-minutes.html People with action items: all jan jeanne jr[End of scribe.perl diagnostic output]