See also: IRC log
Yes, please
<Jan> Scribe: jeanne
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0072.html
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0060.html
JR: This term is used in WCAG and section 508, so we are changing our term to match there. Programmatically Determinable
<Jan> programmatically determined (programmatically determinable):
<Jan> When information is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. For non-web-based user interfaces, this can mean making use of platform accessibility services, general-purpose APIs, and in some cases a Document Object Model (DOM). For web-based user interfaces, this means following WCAG 2.0...
<Jan> ...so that user agents can pass on the information.
SN: In some cases the DOM has the context of being web-based
<Jan> programmatically determined (programmatically determinable): When information is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. For non-web-based user interfaces, this can mean making use of platform accessibility services, general-purpose APIs, and in some cases a document object model. For...
<Jan> ...web-based user interfaces, this means following WCAG 2.0 so that user agents can pass on the information.
JR: SO you suggest you remove DOM
<Jan> Resolution: Alll accept the new wording: programmatically determined (programmatically determinable): When information is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. For non-web-based user interfaces, this can mean making use of platform accessibility services, general-purpose APIs, and in...
<Jan> ...some cases a Document Object Model (DOM). For web-based user interfaces, this means following WCAG 2.0 so that user agents can pass on the information.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0062.html
JR: There were potential legal issues to potentially disparaging a 3rd party format
<Jan> Text Alternatives Preserved: If the authoring tool provides transformations that preserve non-text content, then text alternatives for the non-text content are preserved if possible in the output technology. (Level A)
<Jan> Text Alternatives Preserved: If the authoring tool provides transformations that preserve non-text content, then text alternatives for the non-text content are preserved if the output technology has equivalent mechanisms for encoding that accessibility information (WCAG). (Level A)
GP: It shouldn't have to be equivalent, also provides a mechanism is enough.
<Jan> Text Alternatives Preserved: If the authoring tool provides transformations that preserve non-text content and the output technology has mechanisms for encoding text alternatives for the non-text content, then text alternatives for the non-text content are preserved. (Level A)
<Jan> No objections: "If the authoring tool provides transformations that preserve non-text content, and the output technology has equivalent mechanisms for encoding that accessibility information (WCAG), then text alternatives for the non-text content are preserved."
AC: The new wording is good, but it is another area where you have to do a WCAG audit between two sites, we need to highlight the parts of WCAG That people should be looking at.
JR: An included technology, is any one or technologies that the claimant choses to conform to ATAG. There may be many different formats, but the (For example) html to pdf is conforming, but html to svg may not be in the conformance claim.
GP: @@ has the issue of transforming gif images. Would this only concern the gif, or would it also include the gif and the enclosing html with the alternative text?
JR: It would not really be a
transformation, it would include the enclosing html
... The problems were legal problems with "preserve" and
"warn", because the warning had legal ramifications. There
needed to be a third option that didn't involve a
warning.
... we went back to basic need to alert the user that
information was being lost, therefore we went to
included.
... so if the developer doesn't want to warn, they can check,
which would give the alert to the user that the alt is
missing.
<Jan> Resolution: All accept: "Optimizations Preserve Accessibility: If the authoring tool provides "optimizing" transformations then any *accessibility information (WCAG)* in the input is preserved in the output. (Level A) "
<Jan> Resolution: All accept: "If the authoring tool provides transformations that preserve non-text content, and the output technology has equivalent mechanisms for encoding that accessibility information (WCAG), then text alternatives for the non-text content are preserved."
<Jan> "Restructuring and Recoding Transformations (WCAG): If the authoring tool provides "restructuring" or "re-coding" transformations, then at least one of the following is true:
<Jan> Note: This only applies to transformations in which the output technology is an *"included" technology* for conformance.
<Jan> (a) Preserve: accessibility information (WCAG) is preserved in the output; or
<Jan> (b) Warning: authors have the default option to be warned that accessibility information may be lost (e.g., when saving a vector graphic into a raster image format); or
<Jan> (c) Checking Active: accessibility checking is active on the output; or
<Jan> (d) Checking Suggested: authors have the default option to have accessibility checking suggested."
<Jan> JS: Would like to choose a different e.g. maybe captions
<Jan> (e.g., when converting from a video format that has text tracks to store captions to a video format with no text tracks)
JR: I've seen software that can transform 50 or more formats, some will be accessible, some will not.
<scribe> ACTION: Jan to take the examples discussed and add them to the implementing document for B.1.2.1 [recorded in http://www.w3.org/2010/11/12-au-minutes.html#action01]
<trackbot> Created ACTION-309 - Take the examples discussed and add them to the implementing document for B.1.2.1 [on Jan Richards - due 2010-11-19].
http://www.w3.org/WAI/AU/2010/ED-ATAG20-20101108/
JR: Platform conventions" term
was added several years ago when not all major platforms had
accessibility APIs.
... I proposed splitting it up where the accessibility APIs
exist, and follow platform guidelines where they don't exist.
So there will be two success criteria. All the different APIs
will be explained in the supporting document.
SN: It seems like a reasonable approach. I think it covers it.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0061.html
<Jan> Resolution: All accept: A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow user interface accessibility guideline(s) for the platform. (Level A) Note: If a conformance claim is made, then the claim cites the guidelines followed.
JR: both are level A
<Jan> Resolution: All accept A.1.2.2 Non-Web-Based Accessible: Non-web-based authoring tools implement communication with platform accessibility service(s). (Level A) Note: If a conformance claim is made, then the claim cites the platform accessibility service(s).
<Jan> Resolution: All accept: "Change "platform accessibility architecture" to "platform accessibility services" as IBM commenters requested (this also agrees with Section 508 refresh)."
harmonization is desirable.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0039.html
JR: We are clear that it is status information. Instead of sending the API "this is underlined in green", the API receives, "this is a grammar error"
AC: rewording is good.
<Jan> Resolution: All accept: A.2.2.1 Editing-View Status Information: If an editing-view modifies the presentation to convey status information, then that status information can be programmatically determined. Status information conveyed by modifying the presentation of editing-views may include, but is not limited to, spelling, grammar and syntax errors. (Level A)
JS: I like to include the note in the SC where possible, because I see that WCAG is copied and pasted by others and the notes are often lost.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0039.html
<alastairc> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0071.html
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0071.html
AC: TinyMCE would then pass because if you move the focus into a heading, and you move into it, the dropdown menu allows you to select the next one.
JR: Greg Gay and I added a feature to TinyMCE to display where you are in the hierarchy and it allows you to move to the next easily. What we want is to reduce the number of keystrokes, so it deals with structural chunks rather than having the user have to drag select.
<Jan> A.3.4.1 Navigate By Structure: If editing-views expose the markup elements in the web content being edited, then the following are true: (Level AA)
<Jan> (a) content representing markup elements are selectable (e.g., content renderings, source content, etc.)
<Jan> (b) navigation mechanisms are provided to move the selection focus between elements
<Jan> Resolution: All accept A.3.4.1 Navigate By Structure: If editing-views expose the markup elements in the web content being edited, then the following are true: (Level AA) (a) content representing markup elements are selectable (e.g., content renderings, source content, etc.) (b) navigation mechanisms are provided to move the selection focus between elements
<Jan> Resolution: All Accept: A.3.4.2 Navigation of Programmatic Relationships: If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided supporting navigation between the related content. (Level AAA) Note: Depending on the web content technology and the nature of the authoring tool, relationships can include element nesting, headings, labelling,...
<Jan> ...programmatic definitions, ID relationships, etc.
<gpisocky> Sorry to interrupt: Tim Boland is trying to get in, getting a conference is full message no more parties can be added, wants to know what to do.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0068.html
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0068.html
JR: there is a new definition. author actions prevent generation of accessible web content (there are so many I thought this deserved its own defn):
When the actions of authors prevents authoring tools from generating accessible web content (WCAG). Examples include:
- turning off accessibility options
- ignoring prompts for accessibility information (WCAG)
- providing faulty accessibility information (WCAG) at prompts
- modifying the authoring tool (e.g., via scripting, macros, etc.)
- installing plug-ins
- etc.
AL: it repeats information that is required in other places.
JR: the ffrustration that we are trying to counter, is when the transformation introduces an accessibility problem and the author doesn't discover it until much later in the process.
AL: So we are trying to push discoverability earlier in the process.
JS: the biggest complaint I received from users at an accessibility conference was that CMS systems stripped accessibility information.
AL: automatic means that there is no human intervention. It sounds like there is a human intervention when you split it.
JR: Humans often initiate the intervention - a user may select a color red, the tool creates the code the insert that code.
AL: I look at it more at a macro level. Example of a weather problem in FexEx that would produce a cascade of automatic information to reroute and reschedule packages.
<Jan> (was B.1.3.1) Auto-Generate Accessible Content for Publishing (WCAG): *Authors* have the default option that when *web content* is *automatically-generated* for *publishing* after the *end of an authoring session*, the content meets the WCAG 2.0 success criteria. NOTE: This applies only to automatic processes specified by the authoring tool developer. This does not apply when *author actions...
<Jan> ...prevent generation of accessible web content*.
<Jan> ResolutioN: All accept: (was B.1.3.1) Auto-Generate Accessible Content for Publishing (WCAG): *Authors* have the default option that when *web content* is *automatically-generated* for *publishing* after the *end of an authoring session*, the content meets the WCAG 2.0 success criteria. NOTE: This applies only to automatic processes specified by the authoring tool developer. This does not...
<Jan> ...apply when *author actions prevent generation of accessible web content*.
<Jan> (NEW SC) Auto-Generate Accessible Content for Authoring (WCAG): *Authors* have the default option that when *web content* is *automatically-generated* for an *authoring session* then one of the following is true:
<Jan> (a) Accessible: the content meets the WCAG 2.0 success criteria without author input; or
<Jan> (b) Prompting: during the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
<Jan> (c) Checking Active: after the automatic generation process, accessibility checking is active on the output; or
<Jan> (d) Checking Suggested: authors have the default option to have accessibility checking suggested.
<Jan> NOTE: This applies only to automatic processes specified by the authoring tool developer. This does not apply when actions of authors prevent generation of accessible web content (e.g., by providing faulty accessibility information, by installing additional plug-ins, by writing custom automated scripts, etc.).
<Jan> - 3 WCAG levels
<scribe> ACTION: AlexLi to review the proposal for auto-generation from email: http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0068.html [recorded in http://www.w3.org/2010/11/12-au-minutes.html#action02]
<trackbot> Sorry, couldn't find user - AlexLi
<scribe> ACTION: Li to review the proposal for auto-generation from email: http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0068.html [recorded in http://www.w3.org/2010/11/12-au-minutes.html#action03]
<trackbot> Created ACTION-310 - Review the proposal for auto-generation from email: http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0068.html [on Alex Li - due 2010-11-19].
<Jan> Resolution: Remove SC B.2.2.2 Availability.
<Jan> ResolutioN: All accept: Publishing: ANY point at which the authors or authoring tool make web content available to end users (e.g., uploading a web page, committing a change in a wiki, LIVE STREAMING).
AL: What is the difference between the proposals?
JR: The difference is to make commenters understand that we have considered the complexities of when content may be published.
<Jan> Resolution: Accept: Implementing ATAG 2.0 Appendix E on "Real-Time Content Production" renamed "Authoring Tools for Live Web Content" to match WCAG 2.0's use of "Live"
JR: rename to "Live" web content - based on WCAG
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0064.html
JR: I propose to remove it in response to a number of comments. All of the examples I can think of are already covered by WCAG, so if a tool is meeting WCAG, then it doesn't matter that it can't edit images.
<Jan> Resolution: Remove B.2.1.3 Other Technologies
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0070.html
AL: there are templates that are
filled out by a wizard process, so the author may not be aware
of where it comes from.
... what if the template is relatively accessible, but has no
instructions?
JR: If someone requests a template that is a form template, and you asked what questions you wanted to ask for the form, and the tool didn't create labels for the form.
AL: I am thinking more about WCAG instructions for the descriptive title.
<Jan> ACTION: JR to Consider how http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0070.html might be made more consistent with new auto-generate wording [recorded in http://www.w3.org/2010/11/12-au-minutes.html#action04]
<trackbot> Created ACTION-311 - Consider how http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0070.html might be made more consistent with new auto-generate wording [on Jan Richards - due 2010-11-19].
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0065.html
<Jan> A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient. (AA)
AC: How to test "efficient"
AL: Just test for Ctrl-C, Ctrl-V, F4, etc.
JR: In TinyMCE instead of toolbars, you can jump right into the content area.
AC: How would it apply to a wiki that is essentially just text?
JR: It would skip right to the start of the content. It is AA.
AL: would it be applicable for a toolbar?
JR: If you can move between toolbars and then move down, that would apply.
AL: Something has to make it more efficient, and how do you measure that?
JR: More efficient than straight-line keyboard navigation through the interface.
AC: That there is some change made or effort made to improve the navigation
<Jan> A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than basic sequential keyboard naviagation. (AA)
"more efficient than basic sequential navigation"
scribe: Keyboard shortcuts, bypass links, navigation shortcuts all count.
AL: "More efficient than" may require a definition.
<Jan> Resolution: All accept: A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than basic sequential keyboard naviagation. (AA) with def'n
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0058.html
JT: How would this relate to tools that are mashups? That is frequently the case in learning management systems
JR: We draw a box around what is declared to be the authoring tool. (These 4 pieces together are claiming ATAG conformance)
<Jan> Resolution: All accept: http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0058.html
<Jan> AC: Would like to think more about it.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/acept/accept/ Succeeded: s/becasue/because/ Found Scribe: jeanne Inferring ScribeNick: jeanne Default Present: Jeanne, alastairc, Jan, Cherie, Jutta, +1.571.765.aaaa, Greg, AndrewR, +1.561.582.aabb, Sueann, TimB Present: Alastair AlexLi AndrewR Cherie Greg Jan Jeanne Jutta Sueann TimB Agenda: http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0072.html Got date from IRC log name: 12 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/12-au-minutes.html People with action items: alexli jan jr li[End of scribe.perl diagnostic output]