Agenda is to resolve Issues raised during last call.
JT Covered in WCAG already.
PJ This is more important when we are dealing with a user agent.
JT Quite a few WYSIWYG tools move the content around through positioning tricks that re-order the presentation without reordering the document source. But this is already covered in the WCAG
PJ An example where it is not addressed is a MAP which has AREA somewhere else, not related to the presentation
IJ The IMG element does not need to be located with the MAP
WC If someone doesn't load the image they should get the order right still. This is very fine HTML.
PJ I think it is more user agent than tool issue
DD In this case there is an explicit link to the MAP
PJ If you're just a screen reader you don't understand that link
JT It is also an AU tool
PJ It is really UA
JT There are tools that let you create a file out of order
CMN for example you can take a paragraph from the end and have the CSS generated to make it first
PJ Why ask the AU tool, and not the user agent?
WC in the example of MAP it is user agent, but for style sheets you have to rely on the order, and then it is covered by 6.1
PJ We should note that it is covered by WCAG and UA
DB Thre are times when you want to be able to control the order, eg put a navbar at the bottom and make it present at the top
Resolved: covered by WCAG and UA@@
JT Raised by Jim Thatcher.
PJ This is the tool and the author
JT What we need to put here is clarification. Generally we need to distinguish what is done by the tool
IJ All checkpoints use imperative for tool
JT That might be too subtle
PJ I didn't know it
WC If I don't use a WYSIWYG tool, and I hack the HTML...
JT He's saying that is the author's choice.
GR If you are asking it to transform into a table it can ask for the accessibility information
JT The point is good - there is a misunderstanding of what is the tool's job and what is left to the author. We need to acknowledge that the tool cannot produce the content by itself
WC That makes sense. I think a lot of the checkpoints get it
JT Make a clarification, or in the introduction?
DD Say in the intro that anything that is directly done by the author like editing the source is beyond the control of the tool. It has to check what they do.
PJ 1.2, 2.2, 4.3 are closely related - we need to write them carefully to make sure they do not get confused. So 1.2 the intent is that the tool needs to generate content automatically that conforms.
WC say "ensure automatically generated content conforms
DB Need to distinguish what can and what must
PJ This seems to fit in 2 - generating standard markup
IJ/JT That would work well
BR 1.2 could say support production of content that conforms to WCAG
JT No, propose moving it to 2 and say "generate content"
PJ 2.2 says that already
IJ 1.2 is accessible markup, 2.2 is in conformance with a published specification
GR Do we want to maintain the idea that the tool should prompt for information, etc.?
IJ isn't that 1.1?
GR No. For things that need manual checking we should say so.
JT If we say 1 is what we want the author to do, 2 is what we want the tool to do, we have to make sure that is there.
CMN Guideline 3 is all about this
DB The intro to 1 talks about auto-generated markup - we would need to change that
PJ Do we agree that Guideline 1 is for the author and guideline 2 is for the user agent?
CMN No, that represents a big change
IJ We could split 1.2 into author and auto
PJ is that different from 2.1?
IJ Yes
CMN The logic was that 2 talked about general conformance to standards, and then 1 talked about conformance to accessibility standards in particular
PJ I want to open with "support the accessibility features" and separate that out from being standard compliant.
JT So 2 was in support of standards. Do we need to clarify the role of the author vs the tool in 1.2?
PJ 1.1 - Ensure the author can ... 1.3 is ensure the templates are... so 1.2 is about markup generated by the tool.
IJ 2 is about generating standard markup. "generate generate generate". Maybe we should reword guideline 2 to de-emphasise the tool's role.
JT So at 1.2 we are mixing the author's responsibility with what the tool does.
CMN 1.2 is about generated markup - we should say "generate markup". Jim wants to be able to enter non-conformant markup
JT We could split 1.2 to have support the author, and another for the tool.
CMN We have guidelines 3 and 4 to cover support of the author
GR We need to make the point that it is possible to add accessibility content during generation/transformation. We want to say don't lose anything, and allow adding
CMN I agree. I think that 3.1 covers the precise case...
PJ You could conform to 1.2 if there is one way to fix the source. 3 and 4 talk about additional ways to do it. You could meet 1.2, but not 3 and 4, if you don't have the prompting. We have to give the tool vendor minimum guidance with the split.
IJ I would suggest looking at the imperative verbs to ensure consistency. If we use "generate" to consistently mean what the tool does without author control then we should have a different verb for what the author does
PJ I would like "author" and "tool" to be there. for example "ensure the author can use", or "ensure the tool generates"
IJ I agree
Resolved: Do this in an editorial pass - each checkpoint to say "author, tool, ..." and verbs to be used consistently
JT So do we want to split 1.2?
No
JT Our response is that we will change the wording to make it clear that this applies to what the tool does.
PJ I want a where possible, or can
DB are we not looking at the question of whether 1 and 2 are mixed? They seem to be - 1 is mostly about auhtors, 2 is mostly about tools
JT Yes, but the split we are using is standards in general and accessibility in particular
DB I can't see that much difference - for example 2.3
CMN Does the proposed response answer the issue?
JT I think so.
PJ My wording issue on 1.1 may be relevant
...
CMN Ensure the tool allows the author to use accessible authoring practices
IJ I wanted carry out, not implement
PJ Agree
IJ I don't like use
WC Follow?
we like follow...
Ensure the tool allows the author to follow accessible authoring practices
BR We need to define accessible authoring practices
GR the reason for implement is that Judy felt it it wasn't strongly enough worded. This would allow a text editor to meet the checkpoint.
CMN Yes, but there are others it doesn't meet
defining authoring practices...
CMN Accessible authoring practices are the things the author does to make their content accessible
PJ Direct editing, alternative content
WC You don't want to say this is just WCAG.
DB The problem is the definition for accessibility is circular.
IJ I asked Gregg how to define accessibility. "Anything that you do so disabled people can use the web".
GR I think it is a red herring to define accessibility
DB I need a definition
PJ I define it as the attributes of the tool, content, etc. Accessible is a list of things that need to be done, combined with an appropriate technology you have an experience where the person with disability can use the product
JT We had "direct accessibility" and "accessibility through assistive technology"
GR IJ is right for the purposes of this document.
GR Rather than use accessible in the defintition of accessible authoring practices
DB if we have a definition of accessible we can use that rather than use it each time
BR accessible authoring practices are what I want
PJ we should give examples in the definition
CMN eg "Accessible Authoring Practices are things an author does that make their content useable by people with disabilities. For example, providing alternative content.
GR could use "practices".
back to 1.2...
PJ If it has to produce accessible content, why does it have to be over-rideable
DD 4.3 is for thins the tool does not support
JT I think we need to clarify 4.3 to make sure it is clear
CMN I think we should cross-reference to 4.3
JT We don't want to highlight them as the same, we want to higlight the difference (that a tool may not be as smart as the author).
WC say that in the checkpoint
DD The thing is "when the author knows better"
PJ We should add the word accessible in 4.3
CMN The tool doesn't know what to allow override on. So we can't say it clearly...
WC Someone could put in inaccessible markup if they have override power
DD That's fine. That is not a tool issue?
WC if the tool is allowing override, does it have to say "I can't tell?"
PJ 4.3 says the author can override 1.2
BR 4.3 is importing markup that the tool doesn't get
PJ imported or any?
CMN it could be typed up
PJ it is not necessarily imported. The author can override - that was Jim's issue in 1.2
WC side question, did anything meet conformance
Not Yet
GR In HomeSite evaluation, they could get triple-A if they fixed some serious problems.
PJ the question is can anyone conform?
WC So 4.3 could be worded better. Basically we are saying "allow the author to override the tool".
BR To override the tool is too general. I think as it is here is fine
DD How about allow the author to force the tool to retain markup?
PJ As a P2? It covers the ability to post stuff in.
CMN You need to allow external things to come in, but you don't need to require that the author can add code in a given tool.
BR if the tool brings in stuff the author can force it to remain.
WC I like the idea of retain. I used an element in a tool that were unsupported and it would convert markup. I don't want it to change or remove...
DD Good example is new event types. onActivate is not in HTML but with a browser that suports it I want to add onActivate to my source and not have it thrown out. I want a validity check to learn that.
PJ It may not know how to deal with it but it doesn't remove it.
"allow the author to preserve markup not recognised by the tool".
Resolved: 4.3 to be "allow the author to preserve markup not recognized by the tool" (And we like the dialogue technique)
PJ there are tools that cannot support a document because they don't understand it. We should note that we recognise this possibility. For example you can edit the source and preview in a browser and not be able to do WYSIWYG editing.
PJ We haven't defined published, and it may not be necessary if there is a tool. We haven't defined languages that are accessible. To say something conforms to 2.3 you need a W3C spec or a W3C note that says "XX" is accessible.
WC ebook could become an accessible spec.
PJ Can the W3C publish a note recognising ebook as accessible?
IJ I think that is an issue of validating a conformance claim, at WAI CG
PJ 2.3 says "ensure your thing produces in an accessible language". I want the W3C to tell me what is accessible.
IJ I don't think it would be desirable to centralise the endorsement at W3C.
DD I think it is related to WCAG. If WCAG covers ebook, LaTeX, etc then these guidelines are applicable. If WCAG doesn't provide for that there is not much we can do. If you can say "my XX file is WCAG compliant".
PJ This is the language
IJ If one can write WCAG-compliant pages the language enables accessibility.
CMN We could say "use a language that enables writing WCAG-compliant...
JT We should keep the point that we require coverage for extensions, new languages, etc.
IJ It belongs in the conformance
GR It might fit into a note in 2.2, or in techniques
PJ How does someone know if their language is accessible?
CMN We should note in techniques for 1.2 that some languages make that easier.
JT The important thing was to allow content that conforms to WCAG
Resolved: Remove 2.3
BR What is a published specification?
DD We have to answer "what is an applicable language" first. Let's say I have a text editor that generates some markup. I could generate WCAG-compliant stuff that is not HTML - what does it mean?
WC The reason for W3C specs is because they have accessibility review. This carries some of 2.3
IJ 2.1 says "use these".
DD It is worth giving a list of what w3c specifications are applicable?
JT Would your concern be met by noting it in the techniques?
DD I like the WCAG wording. "Use appropriate W3C technologies..."
PJ Should add "supported by browsers"
Resolved: Use the latest versions of W3C recommendations when they are available and appropriate for a task"
DD The second one is to promote the generation of valid stuff. We should stress that point.
WC We don't care here if it is a W3C rec or some other specification
DD Ensure that the tool generates markup that conforms to a public specification
DB What does this have to do with accessibility?
JT This addresses the issue of creating access tools - you have to have the spec, or reverse engineer it, to create the assistive technology.
DD Even if the vendor does not support accessibility then it is possible for a third party to work with it.
WC If this is a proprietary spec then it has to be accessible
PJ It has to be able to be proprietary and conform.
WC There are two points. 1 - it must be valid. and 2. does it have to be a public spec?
PJ We need a checkpoint that says "make valid markup"
DD The part about the published should be folded into the first checkpoint.
PJ It is possible to use a tool that is publicly specified instead.
CMN A specification does not need to be free to be published
JT The problem is if it is not free can people make a User Agent?
GR If you are going to use these things then allow the author to transform this stuff.
CMN If you write in a language that isn't accessible then you fail WCAG, and you lost.
GR We should say "allow the user to transform or add namespaces"
WC That becomes a WCAG problem (or User Agent). What we need here is to require validity.
Resolved:We want 2.2 Ensure the tool generates valid markup.
DD Whenever you extend an industry standard, let the author know you are doing that.
WC HomeSite does that nicely - you can generate W3C strict, or X compatible, or ...
DD I want a checkpoint.
WC 2.2 should allow you to select what you are going to validate to. we need a checkpoint that says "use standard markups".
GR Ensure the author can validate against generic standards.
JT We want to alert the author when we are not using the industry standards
PJ What is the industry standard?
WC In the web there are w3c standards, but there are various other standards groups
GR NISO, ISO, ...
PJ I would accept DD's proposal as a priority 3.
Proposed: "Ensure the author can choose to generate markup that is valid to industry standards"
GR You need to be able to validate proprietary stuff against vendor-neutral
WC Often tools take a specification and add things. we are trying to discourage that.
Resolved: New 2.3 "If markup generated by the tool differs from W3C standard, inform the author." P3
/*lunch*/
JT Is there something we are not covering?
PJ I think it is a technique
Resolved: This is techniques
JT This is already a gimme.
DD The issue is between 3.2 and 3.3. If you have nothing else to use it is OK to use what the tool guesses.
WC No. If the author hasn't provided anything it shouldn't add an alt attribute.
CMN Forces an accessibility error to be caught by 4.1 If it is caught, then it is a user agent
PJ The tool should keep track of known objects.
DB What if I am building a huge database?
PJ You can encode it in the file format, but filename is not usually worth having. The tool doesn't know.
Resolved: Leave as is
BR A word-processing document or spreadsheet could have multimedia.
JT I think he was talking about objects prepackaged
CMN There are two good things there. Auto-generate/extract accessiblity information.
Good Technique for 1.2
CMN And think beyond multimedia as things that have accessibility information.
DD The note is too broad. Is it just for images?
Note should say "don't use for automatic insertion"
PJ Why is 3.3 P2, and 1.3 P1?
WC This is more context-dependent.
PJ It would be good if the tool shipped with working examples
WC Are scripts included in this?
CMN Depends whether they are templates or multimedia...
JT We want the checkpoint, want to change the note, question the priority.
DB The author can add their own text
BR It is not make or break right?
JT Should templates and this be same priority?
PJ Yes. and they should be P2
CMN It is P1 on our goal to have accessible content by default (relative priorities)
PJ I think is undue burden to require it for all templates.
DD Why? Which ones? They all have to be accessible.
PJ The ones that have tons of templates will take releases to fix them all.
DD Whether it is difficult is not a determinant of priority
GR For the average user they need to use the templates.
WC If someone uses templates and it says at the end "the template was no good" then the tool will look silly.
PJ Yes.
IJ Should they be combined?
CMN I don't want to.
DB Will just alt-text be enough?
PJ No, depends on WCAG. If it is a complex image it should have a long description too. If it is a movie it should be synchronised.
DB You won't get many libraries with complete longdesc
CMN That's OK - many clip art libraries don't fall into that category.
DD Your concern is quantitative? It is too much work to make them all accessible.
PJ It may be impossible to do something without a text-page alternative.
DD What about saying those that are not accessible are marked as such?
DB We're not going to ship tools that say "this is not accessible"
DD But then if I use a tool's template and it doesn't tell me it is inaccessible that is not acceptable
PJ I don't have to use the templates, I might use them wrong, ...
JT If an author is going to pick a template, they are encouraged if it is accessible.
PJ So why not mke it P1 to have templates?
JT There are tools where is not appropriate to have templates.
PJ What I find is most advanced sites - they create their own templates
CMN Right, but the one-time users won't
JT They are just going to be baffled when it says "you took what we gave you and it doesn't work"
CMN If you don't have accessible templates you are going to break a wole lot of other checkpoints already.
PJ I want to go on record: Having all templates P1 is undue burden - ensure there are templates is P1, having all templates is P2
DB I agree with Phill.
PJ How do I provide an alternative or accessible template for a heavy Java page?
JT Templates allow for the author to add things.
CMN The template can describe some functional alternative which may require further author addition.
GR for example do a Frameset template that has a comment like "place the content of the nav frame in the noframes as well.
WC This is the same problem with the auto-generated stuff.
JT We would need to cross-reference 1.3, 3.2, 3.3 - we need very good techniques for here.
Resolved with dissent (PJ, DB): 1.3 keeps sliding priority
IJ Propose merging 1.3 and 3.3
JT 3.3 could be a P2
PJ Because when you put in a gif the tool will ask for alt, whether or not it has it supplied (P1 from 4.1)
GR It is possible to disable that request.
PJ Note in 3.3 should be in 3.2, new note should talk about videos, graphics, etc.
JT We offer the content provided as a default, and rely on 3.2
WC would like to reword to take out prewritten and multimedia.
DB We need to make it clear that this has been included with all things as part of the package.
WC The emphasis is that all the multimedia stuff packaged are accessible.
PJ If we point to WCAG that is an improvement...
IJ Proposes 3.3 to say "ensure prepackaged content conforms to WCAG Example: movies with text and audio equivalents. (Refer also to 3.2)" Sliding Priority
PJ Should we put 3.2 after 3.3?
Resolved: 3.3 to say "ensure prepackaged content conforms to WCAG Example: movies with text and audio equivalents. (Refer also to 3.2)" Sliding Priority, order of 3.2, 3.3 reversed
Resolved: Already covered
DB Can you point to a web-based tool to do your checking?
BR You then have to be online
CMN Your conformance statement has to state the scope ("used online")
PJ I can add anything I want to TopPage
WC HomeSite links to W3C validators
PJ TopPage lets you plug in whatever you want
DD I am concerned that then the requirement is for the tool to be used online. I would like to see a lower priority to ensure that the tool can be used offline.
GR I think it is less of a burden to say "get online" than to give them an outmoded checker. We shouldn't exclude the possibility. We should still encourage people to include something local as well
IJ Do you have to provide it natively?
GR I don't want to kill off a tool made in a garage that relies on other web-based services.
DD It is unlikely to get integrated. All 4 can be done, but they may not be compliant with 5.
Resolved: This is techniques material
CMN We decided not to require particular views.
PJ Providing different views means you don't need assistive technology to see how it looks
CMN This goes back down the path of suggesting there is "a" graphics view and "a" text view, which is not true
JT Do we want to have this in techniques?
WC Part of this is relevant to 4.2 - make people do user testing would be ideal, but showing them a simulated alternative view is a technique.
Resolved: Different views is a technique. In 4.2 we want to simulate other views, and would like to have interactivity in it
DD We might ask the author to provide the flexibility about how checking happens. My concern is that people will take the checkpoint and interpret it as requiring lots of interruptive prompting, and claim that the guidelines are unimplementable.
JT We took it to techniques and intro on the request of developers.
Resolved: No, it doesn't.
WC I think that is in 4.2
JT Checking for and alerting the author requires some author participation
PJ Spell out in the note that the vendor doesn't have to make telepathic tools - it may require author participation, and some things may not be possible. What if I don't include function to ask the author? Do I conform?
DD Yeah
PJ Make it "that are machine checkable" P1. P2 is things that require author participation..
DB You mean things the tool can't prompt me for?
WC No, things that the tool can determine that it needs something. HoTMetaL asks if you need a longdesc for images?
DD What if you go over your document and add no longdescs, and run your check again.
CMN Then it should remember. It's a design problem
GR Should be like a spell checker.
WC Are we going to say "so, product X does this..."
That would be helpful
DB If I have the questions the tool can't answer in the documentation does that satisfy it?
CMN That's mostly what Bobby does.
DD There are two things - problems the tool can find, and things that the author needs to know, which is a lower priority.
PJ It almost has to have a test for everything in WCAG.
IJ If it is in the documentation, is it insufficiently visible?
CMN The list is - you have to go through the WCAG checklist
DB So at some point I have to tell them about that every time, every session.
IJ Not necesarily
GR Homesite has a project manager that keeps track of what you have changed and what you have to check.
DB If I add new content then I should be warned about all the uncheckable things.
PJ Can I meet 4.1 by prompting the author to check for alt text once? We have to specify what it takes in the techniques document.
PJ The ER doc should be in the Guidelines Document.
Resolved: Put a reference to the ER note in the checkpoint as an informative link.
DD It is essential to give some help
DB 4.1 implies we tell them there is a problem, 4.2 implies an assistive mechanism
JT But it doesn't tell you how to do it.
WC One of the reasons for this document is so we can help authors who have not read the WCAG. Having Authoring Tools that can help is essential.
PJ So for each WCAG P1 I need to help the author fix it.
DB is documentation on how to fix it enough?
DD Yes.
JT We should point this to ER.
PJ We need to be able to sign off on ER.
YES.
CMN So is the minimum requirement to provide context-senstive help?
PJ The requirement for help is not a P1
DB: The crux of the issue is that I don't think assisting is essential. It's important.
Resolved: Think about this overnight
DD Propose to delete Note 2
Resolved: Delete Note 2 from 4.3
JT There are P1 checkpoints that cover the P1 case, and there aren't many cases.
PJ This was so important it actually got fixed...
Resolved: Still P2
Resolved: P2
DD Does that cover everything - checking, etc?
Resolved: Needs rewording to make it clear that it does.
"Ensure that functionalities related to accessible Authoring practices are integrated into the tool".
JT This is P1 because the average author will go for whatever is first
WC If assistance and templates are P1, then this kind of follows.
PJ I want to delete 5.2 and drop 5.1 to P3
JT Using a Math tool, the first choice is to make the math a gif...
PJ When you prompt the author to make content, prompt them with accessible choices first.
DB How do I find out what are the highest priority
Action editors: Add reference to WCAG P1
DB So we tell people to use CSS and make it the most popular, and it isn't implemented properly.
WC This seems like a technique for 1
PJ Could it only be applicable to certain environments
WC Could 3.1 also say "assist the author in providing alternative information and other WCAG priority 1"
Resolved with dissent(CMN,GR): Priority 2.
WC We still don't have a checkpoint that says "help the author"
CMN But we say a whole lot of verifiable things like "prompt for alternative information" and ...
WC Propose: change 3.1 "prompt" to "assist"
Resolved: 3.1 "Assist the author in providing equivalent alternatives to content"
JT Propose: add "structure" to 3.1
Proposed 3.x "Help the author create structured content"
Resolved: new 3.x "Help the author create structured content"
Proposed: Guideline 3: "Support the Creation of Accessible Content"
/* dinner time */
Second day (Phill is not here yet)
JT currently sliding scale
DD I don't get what the "built from several parts" means.
JT It means you can provide examples that are not accessible as part of building complete examples.
GR It was pointed out that saying "you can't show how to do layout by tables" then it wouldn't fly
DD So clarify the wording. "Ensure that documentation examples show how to produce accessible content" does not need a note.
DB So what do we have to do when we say how to build a table??
DD Mentioning counter-examples might clarify what the note says
CMN ...or identify inaccessible solutions
DB So if you are producing something where you need a text-only version for accessibility do you need to show how to do a text-only version each time?
/* Phill arrives
JT You could link everywhere to the one example
DD so for an IMG you can build up a progressive example
GR You don't want to teach people through negative examples. We used to say "when giving examples make sure the illustrated example is WCAG compliant (and valid)"
JT What about practices that are not accessible
GR I would not use IMG for an example
DD I think it is OK to introduce a concept bit by bit. You progressively introduce things until you have everything.
GR Yes.
Resolved: remove the Note from 6.3
DB What do we do about saying how to use layout tables?
GR Say "the preferred practice is X, there are alternatives Y and Z", for example with a link to the relevant section that has the preferred example.
IJ Would you be showing table markup?
DB They would be showing tables for layout.
PJ Tables for layout are perfectly accessible - still meets WCAG guidelines
JT Do we want to put into the guideline something that says "the accessible example is part of the example.
DB This gets too far into the detail - at what level do you need to link what?
JT What if we added "...as part of the example"
GR Then we are going to get into the making it most obvious...
CMN For which we already have a checkpoint.
GR If someone uses the tool to learn the language
WC As long as they point to WCAG they have lots of examples
CMN No, that is not sufficient.
GR The point is to avoid the ghettoisation of accessibility
JT Which is why we want ti as part of the example
DB So maybe you need some phrase added "...or indicates how it isn't compliant" - adding the accessible example is going to be very hard (although it is already a load of work lined up).
CMN Sounds good to me. The key is that for any example, you can find out how to do it accessibly (which might be "make another, accessible version as well").
IJ "Ensure that all examples conform to WCAG, or explain how they don't"
PJ "include examples that..."
DB No, that is changing it
DB We don't have to require examples
JT Use "...includes how to ..."
DB Makes no big difference
GR There is a user group of people who learn through the help of a tool.
JT Kynn wanted to be able to have alternative ways of doing things, and the wording had to enable that.
IJ Ensure examples illustrate accessible authoring practices or explain why they don't.
BR 6.2 covers authoring practices
IJ 6.3 is specific to WCAG
DB The problem is whether it is interpreted as making the HTML that the help is written in is compliant?
CMN The use of "author" and "tool" (see resolution yesterday) will clarify this.
DB I like the new wording, but maybe "employ" instead of illustrate
JT That gets confusing again whether it is showing or being written in accessible way
IJ in each example ensure that pertinent accessible authoring practices are included.
DB Do I have to have every example show every accessible authoring practice
CMN No - for example if you illustrate some things which require text-only versions you don't need to show how to do that every time, just mention each (relevant) time that it needs to be done.
GR I don't feel that we are hitting the point that if there are two ways of doing something, show how one can make the transformation from one to the other (how to use Style Sheets with deprecated presentation). That is something that help should stress.
CMN We should do some real examples for the techniques
GR We could put a sentence or two into the introduction to the guideline.
Action GR: Write technique for this.
CMN "ensure examples include pertinent accessible authoring practices"
IJ I don't think we need to say pertinent
GR There are property sheets in HomeSite, where it has accessibility practices
CMN You need the pertinent practices, not just some relevant practice.
Noted: Accessible authoring practices should point to WCAG.
BR What is different between 6.2 and 6.3?
DB I can use text editor and WCAG and I am in compliance. Why don't I just point to that. 6.2 doesn't say that.
DD To me, the first one is integrate accesibility wherever relevant, second one is to have a section where all the accessibility features are gathered, the third is to make examples.
IJ The wording used in UA is "ensure all tool functionalities that promote accessibility are documented". P1 (UA 5 Oct 12.2) "describe features known to promote accessibility in a special section" P2. (UA 5 Oct 12.3)
/* It's Ian's fault
DB That sounds like what I was getting at
BR 6.2 says how to use the tool, 6.3 says that the examples should show how to make accessible markup
IJ is there a reason to use the term accessible authoring practices?
PJ say "...show how to conform to WCAG". I don't think we should use the term accessible authoring practices
IJ Should we use it in the document at all?
CMN Accessible Authoring Practices: The things that authors do in order to ensure that their content conforms to WCAG
PJ The tool doesn't want to explain what the author does
CMN Examples want to show what the author does.
PJ 6.2 says "show the author what the tool does".
GR Configuration steps, etc
DB There are steps you can take that are tool independent that produce accessible content.
IJ accessible authoring practices is just a phrase for "conform to WCAG"
JT, CMN, right
PJ Confusion between what the author can do, and what the tool can do itself, and how the tool can help the author
JT It is an editorial device
IJ Propose to remove "accessible authoring practices"
BR The important thing is to have a common understanding of the terms.
PJ 6.1 should be about production of content.
IJ saying "accessible authoring practices" you lose information.
PJ 6.1 is integrate features that promote production of accessible content into help. 6.3 is make sure examples show how to produce accessible content.
JT should we remove the term from the document?
PJ The process is more than using the tool. The term implies things that the tool does not do
WC removing it is not going to be trivial
IJ Yes it is.
DB for 6.2 say "in a section, explain features known to promote
JT We don't want to say put it in a special section, and we wnat to say "production of accessible content"
CMN Yes, we want to gather everything - that is 6.2. 6.1 is making sure there is documentation somewhere.
IJ I would like to limit 6.2 to product features
DD It is good that there is a section that explains all the accessibility features
PJ Why is it a P2?
6.2 "In a section of the tool's documentation, describe features that promote the production of accessible content"
DD It is important to have a pointer in help to WCAG
CMN It is a useful technique.
WC why does it have to be together?
CMN 6.1 says "describe the features, somewhere". 6.2 says "put it in one place for people who are looking for accessibility information
priority is open...
Resolved: 6.2 "In a section of the tool's documentation, describe features that promote the production of accessible content"
PJ Do we mean help topics or documentation?
BR We should just say documentation and define it generally.
Resolved: Define documentation in glossary and reinforce this in the introduction.
CMN Proposed 6.1 "Document all tool features that promote production of accessible content"
PJ Point is to integrate
CMN Integrate documentation of all...
CMN We want to say tool features here
DB There is more than tool features - there is what to do to conform
DB "Integrate steps that produce accessible content in applicable documentation
IJ What does 6.1 say?
JT 6.1 says "integrate into documentation how to use the tool to produce accessible content"
DD Documentation is covered as part of 5.1
CMN 6.1 does not need to be as broad as integrating, it is just "make sure that features used to produce accessible content are documented" (and integrating it is covered by 5.1)
DD That's not what we are talking about - there is the case of help for image, and they don't talk about longdesc
CMN That is an example. What kind of instruction is not an example?
JT The initial wording covered integrate and document.
CMN Split out document as a separate requirement (P1)
CMN Proposed 6.1: "Document all features that promote the production of accessible content", P1.
Resolved: 6.0 "Document all features that promote the production of accessible content"
IJ Proposed 6.2 "In a dedicated section, document all features of the tool that promote the production of accessible content".
Resolved: 6.2 "In a dedicated section, document all features of the tool that promote the production of accessible content"
6.1: Ensure documented features are integrated into the documentation
DD We want naturally integrated
DB are we really saying that or are we saying "ensure that creating accessible content is a naturally integrated part of the documentation."
PJ I would like to add "help" here.
BR We define documentation already to include help
IJ When the documentation tells you how to use the tool it should tell you how to use the accessibility features of the tool
CMN Yes, but it should tell you how to do it, whether that is through a tool feature or something the author has to do...
Resolved: 6.1 ensure that the production of accessible content is a naturally integrated part of the documentation.
6.3...
CMN "Ensure that all examples and instruction show how to create accessible content" which is redundant with our 6.1
PJ and covered by 6.0. 6.3 should be "ensure documented examples conform to WCAG.
PJ Are examples covered someplace?
CMN add the specifics to 6.1 - "..including examples" (and drop 6.3)
GR add to 6.1 Note: This includes examples and markup illustrations
CMN I think that is what is meant by example.
proposed 6.1 to replace 6.3 is "ensure that creating accessible content is a naturally integrated part of the documentation, including examples."
PJ Technique: make examples comply to WCAG
proposed 6.1 - 6.3:
6.1: Document all features that promote the production of accessible content
6.2: Ensure that creating accessible content is a naturally integrated part of the documentation, including examples
6.3: In a dedicated section, document all features of the tool that promote the production of accessible content
Resolved: 6.1 P1
DB I think 6.3 is a 3, but I am torn with 1 or 2 for 6.2
CMN I agree precisely
PJ We have too many P1. This wouldn't be one of the first 3 things I would do.
DB sometimes the part that 6.2 covers is as important as accessibility features like checkers
CMN There are different staged approaches relevant to different developers.
DB 6.2 takes the most work.
BR We may need to sort out more carefully what priorities really mean. We set the bar pretty high for a non-trivial product.
DB What about P1, P2, P3 for these (in that order)
IJ I don't think a better understanding will make it clear cut - they are judgement calls. This one is a judgement call I think.
BR I would rather put off assigning priorities until we have a common understanding.
DB We should assign them, and then revisit.
JT 5.1 (integration) is P2. We also have 6.4 - emphasise the universal benefit of accessible design
PJ Isn't that a technique of proposed 6.2?
DB Yes.
BR It is a hard thing to verify.
GR 5.2 being a P2 doesn't imply that 6.2 should also be. If it is not essential to integrate the tool, then it is essential to integrate documentation.
PJ If the tool is integrated, then the help is secondary
CMN I think this is a judgement call.
PJ We have a responsibility to identify only things we think are essential in P1s
BR The risk is having the baby thrown out with the bathwater
CMN Developers have to decide, if they can't meet the thing in one shot, which bit they aim for
GR P1 is the requirements for the tool to make accessible content authoring what tools provide
BR Maybe we need an easier carrot for developers.
Resolved: 6.4 to technique
Resolved (GR dissenting): 6.2 is P2
/* lunch
Resolved: Covered by 7.1 make sure techniques show this
JT There are only priorities in some.
CMN Ian suggested make it P1 unless it is prioritised.
DD We should say the word guidelines in this
PJ Use "guidelines" instead of conventions.
PJ If it is a P3 on list X does the author have to do it for P1?
PJ I would like to import the EITAAC prioritizing to the techniques as further guidance.
CMN Good idea (= action charles...)
Resolved: We think this is OK and would like to show in techniques how to map priorities
DB Isn't this a general requirement for software?
CMN I can see that this seems like a general requirement, but the editability of each property is crucial, and it is worth having here.
Resolved: Drop 7.3
PJ Does 7.4 then block a transformation tool from conformance?
CMN No - it is possible to access element properties that a transform will affect, and that can be accessible or inaccessible.
PJ The requirement is not to be able to edit everything there is at all times, but for the editing that is there to be accessible
"Allow the author to edit, in an accessible fashion, all properties of each element supported by the tool"
"Allow accessible editing of all editable properties supported by the tool"
DB A property sheet is a technique? edit source?
CMN Yes (but won't make 5.1??)
CMN I agree with Dick - it is covered by 7.1, but I think it is nice to have it there.
Resolved (DB dissent): 7.4 remains
JT Do we need to say explicitly "make things editable"?
GR for 3.1 I would like "provide a mechanism" not just "assist"
Resolved: It is implicitly covered
7.5, 7.6
JT They are not covered by 7.1 and are specific to authoring tools - it is necessary for people who have reduced access to the document needs an enhanced navigation/editing capability.
BR It says these are specific to Web Authoring Tools, and it is really authoring tools in general.
DB these don't say accessible
DB We are here calling out specific examples that are issues under 7.1
GR Would it be helpful to have problem statements in the techniques?
CMN Yes.
Resolved: 7.6 "enable editing of the structure of the document in an accessible fashion", 7.5 to be "provide an accessible means of navigating via the structure of the document", 7.7 "provide an accessible means of searching within an editing view".
DB I disagree with requiring the feature of a search.
PJ Transformation tools need not provide a search. Should we make 7.7 P3
WC We ought to make 7.7 conditional.
JT It is specified as within editing view - if you don't have one it doesn't apply.
Resolved: Specify that these are within an editing view
DB It would be possible to do structure navigation by searching for elements in a source view.
Noted: DB doesn't want 7.5, 7.6, 7.7
PJ We added a checkpoint - 3.2
CMN That sounds like a lot of words for things we have covered
Resolved: Adopt Jon's proposals as techniques - rest is covered.
BR Should note 3.2 to say separate presentation and structure
PJ add to 3.2 "...and ensure separation from presentation"
Resolved: "...and ensure separation from presentation"
JT There are a number of these that need to be tightened up.
CMN Should be ordered alphabetically
Define generate, produce, accessible content, accessibility, valid markup, user agent
Resolved: Define "priority W" - Call it "Relative Priority"
In these guidelines some checkpoints have a relative priority. This is used to XX the priorities of meeting ATAG checkpoints with the priority for requirements in WCAG
Relative Priority is an ATAG priority 1 for content or features of a WCAG priority 1 Checkpoint
Relative Priority is an ATAG priority 2 when it relates to a WCAG priority 2 Checkpoint
Relative Priority is an ATAG priority 3 when it relates to a WCAG priority 3 Checkpoint
In other words, an authoring tool which claims level-A conformance must meet Relative Priority requirements for priority 1 items in WCAG, while an authoring tool which claims triple-A conformance to ATAG must meet the requirements for all priority 1, 2 and 3 items in WCAG.
The priority definition in WCAG maps because...
Some checkpoints talk about production, generation, checking etc of various content that have different priorities in WCAG. The priority for these checkpoints in ATAG varies according to the priority of the checkpoints in WCAG.
Relative Priority is used for ATAG checkpoints which relate to different types of content, to ensure that the priority of each feature matches the priority given to the feature in WCAG, as follows:
It is priority 1 to implement the checkpoint for content features which are a priority 1 requirement in WCAG.
It is priority 2 to implement the checkpoint for content features which are a priority 2 requirement in WCAG.
It is priority 3 to implement the checkpoint for content features which are a priority 3 requirement in WCAG.
For example, checking for accessibility errors (3.1) has relative priority. This means that it is priority 1 for a tool to check for accessibility errors that are WCAG priority 1, but priority 2 to check for accessibility errors that are priority 2 in WCAG.
Some of the checkpoints in this document that promote the production of accessible content have a relative priority. The priority of each of these checkpoints depends on the degree to which the authoring tool produces content that conforms to WCAG.
It is Priority 1 for an authoring tool to satisfy the most important requirements of WCAG (i.e., the Priority 1 checkpoints in that document).
DB I am confident that we know what we want to make clear, and that it can be done outside this meeting
DB Intro to Techniques is better definition of Accessibility
PJ Can each tool developer make sure that the technique they already use for each checkpoint they meet is in the techniques document (or submit them). Action everyone...
/*JB arrives
JB Will we be ready to ask Tim for a Proposed Recommendation on 22 October?
Maybe.
Resolved: We will try for 22 October (lots of work on techniques...)