Discussed WCAG-EM and EOWG's comments:
Discussed WCAG-EM and EOWG's comments:
Made revisions to Eval Analysis that provides tasks and example use cases for the evaluation documents we are updating and creating.
Briefly discussed accessibility coverage in Web Platform Docs. (See 9 November 2012 minutes for more info.)
Discussed Address Accessibility Early - Eval in Process wiki title:
We started working on the Preliminary Evaluation — notes on this are in 2 November minutes.
<trackbot> Date: 01 November 2012
<shawn> doing checklists - interested in including accessibility Web Quality BP (Elie Sloem, Aurelia Levy) http://opquast.com
Shawn: introductions
Shawn: outlined agenda - background about WCAG-EM meetings, analysis of users/tasks and current documents, preliminary review - quick checks, (just for Shadi's purpose), accessibility in the process - WCAG-EM - evaluating accessibility early in the process
Shawn: discussion re platform document documents in agenda
<ericvelleman> http://www.w3.org/TR/WCAG-EM/
Shawn: Topic: WCAG-EM
<shawn> http://www.w3.org/TR/WCAG-EM/
Shawn: from Tuesday - suggestion to simplify the numbering - TF sorted out the numbering - taking off the overall numbering and leaving the steps numbered with either 1.1 or 1.a
Shawn: polled choices re 1.1 or 1.a - no one feels strongly, but thought was that 1.1 is formal and 1.a is more 'friendly'
Shawn: linking to the definitions - open for discussion from group - linking sections, linking to other documents and internal links
Eric: there are many links such as the word 'website' linked many times and we may want to see if we can drop some of these links.
Shawn: discussion on the pros and cons of taking them out
Shadi: key words in the glossary should be linked. For consistency they should all be underlined. Maybe make an exception for website, but keep others
Shadi: there may others that appear lots in a particular section, but are importedn e.g. 3.2.4. 'relied upon'
Ian: you would assume someone reading this document would understand 'website'. Web Pages is the more complex because of the definition.
Shadi: there is always discussion about what a website it, so that's why it's in the definitions
<Zakim> shawn, you wanted to say link on first occur
Shawn: maybe to link it on first occurrence, or possibly first occurrence in the first section
<Sylvie> +1 for linkingto first occurence in each section
Ian: wonder how people will read the document - each section, or top to bottom?
Sylvia: 1 link to the first occurrence in each section
Suzette: the way the linking is done is endemic - in the definitions the word website is underlined 3 times in its own definition
Eric: a+ for consistency
Suzette: affects the readability and how the document is styled. When you enlarge the font the underlining makes the document more hard to read
Shawn: we are looking again at re-designing the /tr documents
Ian: the best practice for abbreviations or acronyms is to put it in full once
Shadi: in the section with 'relied upon' 3.2.4 Step 2d - comes up a couple of times.
Vivienne: consistency is important
Shawn: what is the purpose of the consistency - smooth reading flow/understanding important concepts.
Shadi: do we even need it at all? What is the purpose of how people use the document - do they need deep links? Do we even need to link any occurrences at all for web pages and websites?
Shadi: look at a different example.
Aurelien: we had a discussion about having a lot of links to external documents. Maybe both of the issues can be solved with hav ing each part of the main documents reference all the external links and all the definitions. This way the text will be easier to read, and we'll still have the definition links and external links at the end. We could have a box floating to the right of the text. We would still have the links butnot in the text.
Shadi: that wouldn't solve it for web pages and websites
Shadi: 2d (relied upon) comes up a couple of time sinthis section. Some underlining are acronyms, some links, some definitions
Ian: none of them are so complex that you need to re-state them in consecutive paragraphs - once per section would be sufficient
Vicki: having something underlined upon 3 times takes away the focus or flow of the document. It may be more distracting than helpful. Link it once only.
Shadi: like the idea of the side bar if that is possible. If relied upon is not highlighted, it looks like just part of the text - and not a technical term
Shawn: maybe just in the top line - methodology requirement - it is bold, in a box - brain says this is the point and everything else is explanation
Shadi: then any important terms in the paragraph should be in the methodology requirement?
Eric: then that would be an opportunity to make the link there and not later
Shawn: in this case the consistency isn't as important or understanding whether people are deep-linking - that's not as important here. Maybe just have it in the first place.
Shadi: 'relied upon' is perhaps an exception.
Shawn: if it is important, it should be obvious.
Ian: provided an example of a sidebar with 'terms used' in a shaded box
Ian: performed a 'screen-reader' simulation of how the text box would work
Vicki: likes the box
Suzette: if the definition didn't make sense, I'd skip it
Shadi: does that mean we shouldn't link it as all?
Shawn: a vote on this? Shawn finds it more distracting
<Zakim> ericvelleman, you wanted to support that sidebar is a bit distracting
Suzette: if this was a paper document - likes to print it out. The print document wouldn't be providing the links. Just because the technology allows us to link, doesn't mean the user has to do it. If you put the definitions at the front, they have to be relied upon to read them. The rhythm can be lost when there are too many definitions as you go. You need to be sure that the document is readable, do the readers really need this.
Shawn: people who are really serious, will read it
Shadi? should
Shadi: linking to definitions is a practice in WCAG - but deep linking is an issue there.
Shawn: for WCAG it is more relevant as you might focus on one portion at a time
Shadi: leaning towards removing all the glossary links
Shawn: poll attendees - Vicki-mention once at the beginning, keep the terms within the document.
Shawn: you have the key terms at the beginning in this document
Vicki: link it once. It is particularly important in that section, maybe link it again there
Sylvie: sidebox could be a good compromise, particularly for important words like 'relied upon' then link them the first time they occur in the section.
Ian: you need to know how big each of the portions are. Average is a couple of paragraphs.
Sylvie: link it the first time
Suzette: eliminate as many links as possible and trust the reader to read the document
Shadi: leaning towards trusting the reader to read the glossary. Where necessary and the reader missing it would have a serious impact, then link it
Ian: not link at all, or once per major section
Shawn: first occurrence or only when really important. Would be inclined to look at the methodology requirements section, e.g. 3d. If there were no more links other than in the methodology requirements.
Shawn: largely agree with Suzette, but because the term is so normal people might not realize it has a specific definition. Prefer very few links - web pages and web sites - maybe just in the scope.
Suzette: if the term is that important it should be in the first sentence.
Eric: have sufficient imput now? yes.
Eric: will take it back to the task force and will get their feedback
Eric: some people want all of them, some want none, and some complain about lack of consistency. The group's input is good and we need to choose one method.
Shadi: we have enough feedback for now on this. We should remove all links to websites and web page - except for possibly one in scope or similar - they are in the glossary. Intuitively most of the key terms - complete processes, relied upon, are explained in the content. Visual appearance, sidebar etc can be discussed - more eye-candy. General process not to linkl except when required.
Shawn: if you end up with just a couple of links, then it should a visually clear link and not as subtle as it is now.
Ian: there are 2 styles of links - different purposes
Shadi: 3 types - to other sections, to methodology requirements and to definitions - are all internal links for consistency use the same type of styling. External links are different.
Shawn: after break - how this relates to other documents in old evaluation suite
<shawn> Old Eval Suite docs: http://www.w3.org/WAI/eval/Overview.html
Preliminary review: it will still be an EO document and WCAG-EM may/may not refer to it
conformance Evaluation: EO had discussed having the conformance in this page be a simiplified version of EM - strong opposition in the TF because it would cause confusion. We talked about that being an overview page. For all of our TR documents, we have overview pages.
Overview pages describes what it is, what it is for, who develops etc.
Shawn: conformanc evaluation page could become the intro for the EM. It would do 2 things - when pointing to WCAG-EM instead of pointing to the TR document, we would point to the intro page. 2) when someone was looking at the Evaluation Suite this would give them a good intro and then send them off there
Helle: you still have to tell people that this is not the actual EM, but is an intro - need the title changed
Shawn: might say "Conformance Evaluation: WCAG-EM Overview"
Shadi: WCAG at glance where there is an obvious outline
Shadi: it is hard to miss that this is a summary or overview and not the actual document
Shawn: the WCAG-EM Overview would have at least the 5 steps, maybe without the abcde
Shawn: from the WAI site itself you would have the quick checks and the WCAG-EM overview - 2 levels without anything in between
Helle: isn't the methodology for someone to do an official third-party type of evaluation. If you are in a developing state, say as the owner, do you then want to go to the WCAG-EM or do you need something like the WCAG-EM but still not as 'official'?
Ian: could the overview page cover both of these ideas and how you choose which method to choose
Shawn: now we have the landing page we don't say much about evaluation - do we need an overall page/paragraph above this?
Shadi: issue is whether creating a 3rd spec, but this is discussion about evaluating through development. In overview document for WCAG-EM, no one is forcing you to follow the whole thing, but you can follow specific parts for your own use. Issue is that we don't want a WCAG-EM light. Resource - how to develoop throughout development.
Ian: conformance may seem a little scary - evaluation is a bit mor friendly
Shawn: look at the titles on each page/section
Shadi: don't you want to signal that this is when you are doing a conformance evaluation
Ian: what are we say that it is - sounds like an official thing.
Shawn: we don't have a good concept on that issue - what we might want to have
Shadi: preliminary evaluation guidance is needed because the target is often non-technical people. Conformance evaluation needs guidance - it is a complex matter and we need to unify the different approaches. In betwen the 2 extremes is a broad spectrum, - depends on skills, role in org. Need a guidance there - best practices for evaluation. Wnat to attract that target audience. Maybe should signal that conformance is the serious stuff. On the [CUT]
page - should describe that depending upon the type of evaluation it provides the guidance on where to look
Ian: the benefit is not just that is not technical - can be done in the day to day work for the developer.
Ian: they will read the quick check, not because it is not technical, but read it because it is short
Suzette: if you're working for abig organization, you must launch bits of a website, you want to test as you go along. Do you then have a QA stage when you test formally or informally just prior to launch.
Ian: in general orgs do little accessibility testing takes place. first step may be for quick checks - performance may come later.
Ian: for organisations there is often not enough time to do a full evaluation - more liikely incremental
Suzette: there may be a scenario between the 2 points. May not need a separate document - but we could provide an indication of how to deal with this.
Aurelien: can use filters so that you get a report for just this kind of thing. We can do a report depending on the 1 element of the web page - eg only the issue related to pop up menus etc. Described how you can choose to report by element.
Suzette: thinking more about 1 particular aspect in a website.
Shawn: re WCAG EM overview page - should get it totally done before the next WCAG-EM.
Eric: want to have it ready for Christmas
Shawn: we'll have our overview ready for then tool
means: too
shawn: contents of evlauation suite -. Evaluation approaches for specific contexts
Shadi: let's wait for this until after the other documents are more stable so that we can see what WCAG-EM covers
Shawn: are the contents of WCAG-EM set?
Eric: yes
Shadi: you can assume that the contents of the WCAG-EM is pretty much set for scope
Eric: we've had a discussion about the roles of people using WCAG-EM
Shawn: Shadi, can you take a quick pass to see what we might want to do with the current documents in the evaluation suites - specific context and combined expertise
Shawn: these 2 documents - specific documents and combined expertise. Based on what's in WCAG-EM we need to figure out what to do with these 2 documents. Should we just point to WCAG-EM or the other way around
Shadi: there may be a need for these documents still - things that don't fit in the other documents. eg large-scale evaluation. WCAG-EM looks at this only from the prformance conformance perspective. With regard to Review Teams we only refer to it as ideal.
Shawn: template for evaluation reports - that is still being debated in WCAG-EM
Shawn: we'll keep watching fdor the specific relationshp betgwen them.
Shadi: coordinating on the naming - eg preliminary evaluation, quick check
Shawn: can that be defined by the next draft
Shadi: would be nice - but not a show-stopper
Eric: agreed
Shawn: by December we plan to have the overview and hopefully the titles
Shadi: and ideally a concept for the evlauation throughout
Shawn: WCAG-EM, WCAG-M - ideas for names?
aurelien: there is a 'c' in there for conformance
Shawn: title is pretty set
Shawn: there has been a lot of discussion on the title
Shadi: WCAG-M is okay but it doesn't translate well.
Shawn: WCAG-EM
Shawn: topic: links out to other documents
Shawn: EO group - anything else you want to ask the TF people
Suzette: has there been more discussion about the sampling methods
shadi: yes, this has been discussed and we'll be working on that within the group
eric: there is the whole aspect of the sampling and the survey we did
shadi: scoring is a controversial issue at the moment
Suzette: sampling is important for constructing the scenarios.
Eric & shadi: we have a big list of comments that we need to cover before Christmas
shadi: we have in several area of the document - sampling where appropriate and that sometimes it is the whole set of pages
shadi: default is all pages, but sampling is usually required
Eric: discussion - we point to other documents and say something about it - you can find out more guidance there etc. Comments made that this wasn't enough and that we should include more, sections or whole documents. we have the idea that you can read it from top to bottom and then you have all the information. Michael talked about that in the meetings.
Shawn: if there is stuff in the background vs throughout the main part of the document
Shawn: there was more linking when the comment was originally made and that has b een taking out
Shawn: when you read through it, how did you feel when you read through, did you feel you were being sent off elsewhere too often, not enough etc.
Suzette: it was more visually disturbing and a little bit cognitively. It comes out at 28 pages when printed. Without the appendix it is 24 pages in normal sized print.
Suzette: it is fair to discretely state that if you want more information in a particular area such as involving users - discuss it and then point to a more in-depth resource
Vicki: I didn't find it distracting - it is nice lilke this
Ian: from maintaining a document point of view, if you start repeating what is in documents elsewhere you have to keep up-dating the documents
Aurelien: External links could also be in a floating box like the definitions
Aurelien: call out could be more visual
shawn: we've been last several months on the EO documents is putting that link at the end - seems to work better both cognitively and visually
shawn: skimming through the conformance steps section (procedure), there are very few links out to other documents in that section. If you don't have links out in that section (EO documents) it might be 1 approach to say that in the steps you don't go anywhere else.
Suzette: 1 to techniques, 1 to EARL or reporting system - also 5d (optional) and techniques in (1e)
Shawn: it would be interesting to check if the person was pointing to the EO documents,
Shawn: in the procedure we don't point to EO documents - just in the background etc
Suzette: should we distinguish between those - the formal approved high level technical reports etc. and these are the EO training materials or however we phrase it
Shawn: EO goes through approval - same as a note for most documents. Wasn't proposing that we state it anywhere, just as a means to explaining it to the person who made the comment
Shadi: comments were regarding normative vs non-normative. We should be careful that it is clear where it is linking to, to give the reader a choice to read now or later. I can continue reading the document and come back to it later. I don't want to focus on what type of a document the link refers to.
Shadi: take that as a staff issue for further discussion. Also language used - should/must. 2 types of documents - working group notes and recommendations
sahdi: working group note - no use of must/shall - only informative
shawn; group input
Ian: the title of the document is conformance - if you want to use that type of idea - that complicates the use of must/shall.
Shadi: there is a push to make this a normative document. We don't want anything to compete with WCAG. WCAG-EM is a way of checking how your website conforms to WCAG. We don't want to confuse the position-makers or the policy-makers.
Ian: you confuse developers that way - the developers already have WCAG
Eric: in the public working draft we have to delete all must, what could we replace them with?
<shawn> EOWG comments http://www.w3.org/WAI/EO/wiki/WCAG-EM_review
Preliminary review: it will still be an EO document and WCAG-EM may/may not refer to it
conformance Evaluation: EO had discussed having the conformance in this page be a simiplified version of EM - strong opposition in the TF because it would cause confusion. We talked about that being an overview page. For all of our TR documents, we have overview pages.
Overview pages describes what it is, what it is for, who develops etc.
Shawn: conformanc evaluation page could become the intro for the EM. It would do 2 things - when pointing to WCAG-EM instead of pointing to the TR document, we would point to the intro page. 2) when someone was looking at the Evaluation Suite this would give them a good intro and then send them off there
Helle: you still have to tell people that this is not the actual EM, but is an intro - need the title changed
Shawn: might say "Conformance Evaluation: WCAG-EM Overview"
Shadi: WCAG at glance where there is an obvious outline
Shadi: it is hard to miss that this is a summary or overview and not the actual document
Shawn: the WCAG-EM Overview would have at least the 5 steps, maybe without the abcde
Shawn: from the WAI site itself you would have the quick checks and the WCAG-EM overview - 2 levels without anything in between
Helle: isn't the methodology for someone to do an official third-party type of evaluation. If you are in a developing state, say as the owner, do you then want to go to the WCAG-EM or do you need something like the WCAG-EM but still not as 'official'?
Ian: could the overview page cover both of these ideas and how you choose which method to choose
Shawn: now we have the landing page we don't say much about evaluation - do we need an overall page/paragraph above this?
Shadi: issue is whether creating a 3rd spec, but this is discussion about evaluating through development. In overview document for WCAG-EM, no one is forcing you to follow the whole thing, but you can follow specific parts for your own use. Issue is that we don't want a WCAG-EM light. Resource - how to develoop throughout development.
Ian: conformance may seem a little scary - evaluation is a bit mor friendly
Shawn: look at the titles on each page/section
Shadi: don't you want to signal that this is when you are doing a conformance evaluation
Ian: what are we say that it is - sounds like an official thing.
Shawn: we don't have a good concept on that issue - what we might want to have
Shadi: preliminary evaluation guidance is needed because the target is often non-technical people. Conformance evaluation needs guidance - it is a complex matter and we need to unify the different approaches. In betwen the 2 extremes is a broad spectrum, - depends on skills, role in org. Need a guidance there - best practices for evaluation. Wnat to attract that target audience. Maybe should signal that conformance is the serious stuff. On the [CUT]
page - should describe that depending upon the type of evaluation it provides the guidance on where to look
Ian: the benefit is not just that is not technical - can be done in the day to day work for the developer.
Ian: they will read the quick check, not because it is not technical, but read it because it is short
Suzette: if you're working for abig organization, you must launch bits of a website, you want to test as you go along. Do you then have a QA stage when you test formally or informally just prior to launch.
Ian: in general orgs do little accessibility testing takes place. first step may be for quick checks - performance may come later.
Ian: for organisations there is often not enough time to do a full evaluation - more liikely incremental
Suzette: there may be a scenario between the 2 points. May not need a separate document - but we could provide an indication of how to deal with this.
Aurelien: can use filters so that you get a report for just this kind of thing. We can do a report depending on the 1 element of the web page - eg only the issue related to pop up menus etc. Described how you can choose to report by element.
Suzette: thinking more about 1 particular aspect in a website.
Shawn: re WCAG EM overview page - should get it totally done before the next WCAG-EM.
Eric: want to have it ready for Christmas
Shawn: we'll have our overview ready for then tool
means: too
shawn: contents of evlauation suite -. Evaluation approaches for specific contexts
Shadi: let's wait for this until after the other documents are more stable so that we can see what WCAG-EM covers
Shawn: are the contents of WCAG-EM set?
Eric: yes
Shadi: you can assume that the contents of the WCAG-EM is pretty much set for scope
Eric: we've had a discussion about the roles of people using WCAG-EM
Shawn: Shadi, can you take a quick pass to see what we might want to do with the current documents in the evaluation suites - specific context and combined expertise
Shawn: these 2 documents - specific documents and combined expertise. Based on what's in WCAG-EM we need to figure out what to do with these 2 documents. Should we just point to WCAG-EM or the other way around
Shadi: there may be a need for these documents still - things that don't fit in the other documents. eg large-scale evaluation. WCAG-EM looks at this only from the prformance conformance perspective. With regard to Review Teams we only refer to it as ideal.
Shawn: template for evaluation reports - that is still being debated in WCAG-EM
Shawn: we'll keep watching fdor the specific relationshp betgwen them.
Shadi: coordinating on the naming - eg preliminary evaluation, quick check
Shawn: can that be defined by the next draft
Shadi: would be nice - but not a show-stopper
Eric: agreed
Shawn: by December we plan to have the overview and hopefully the titles
Shadi: and ideally a concept for the evlauation throughout
Shawn: WCAG-EM, WCAG-M - ideas for names?
aurelien: there is a 'c' in there for conformance
Shawn: title is pretty set
Shawn: there has been a lot of discussion on the title
Shadi: WCAG-M is okay but it doesn't translate well.
Shawn: WCAG-EM
Shawn: topic: links out to other documents
Shawn: EO group - anything else you want to ask the TF people
Suzette: has there been more discussion about the sampling methods
shadi: yes, this has been discussed and we'll be working on that within the group
eric: there is the whole aspect of the sampling and the survey we did
shadi: scoring is a controversial issue at the moment
Suzette: sampling is important for constructing the scenarios.
Eric & shadi: we have a big list of comments that we need to cover before Christmas
shadi: we have in several area of the document - sampling where appropriate and that sometimes it is the whole set of pages
shadi: default is all pages, but sampling is usually required
Eric: discussion - we point to other documents and say something about it - you can find out more guidance there etc. Comments made that this wasn't enough and that we should include more, sections or whole documents. we have the idea that you can read it from top to bottom and then you have all the information. Michael talked about that in the meetings.
Shawn: if there is stuff in the background vs throughout the main part of the document
Shawn: there was more linking when the comment was originally made and that has b een taking out
Shawn: when you read through it, how did you feel when you read through, did you feel you were being sent off elsewhere too often, not enough etc.
Suzette: it was more visually disturbing and a little bit cognitively. It comes out at 28 pages when printed. Without the appendix it is 24 pages in normal sized print.
Suzette: it is fair to discretely state that if you want more information in a particular area such as involving users - discuss it and then point to a more in-depth resource
Vicki: I didn't find it distracting - it is nice lilke this
Ian: from maintaining a document point of view, if you start repeating what is in documents elsewhere you have to keep up-dating the documents
Aurelien: External links could also be in a floating box like the definitions
Aurelien: call out could be more visual
shawn: we've been last several months on the EO documents is putting that link at the end - seems to work better both cognitively and visually
shawn: skimming through the conformance steps section (procedure), there are very few links out to other documents in that section. If you don't have links out in that section (EO documents) it might be 1 approach to say that in the steps you don't go anywhere else.
Suzette: 1 to techniques, 1 to EARL or reporting system - also 5d (optional) and techniques in (1e)
Shawn: it would be interesting to check if the person was pointing to the EO documents,
Shawn: in the procedure we don't point to EO documents - just in the background etc
Suzette: should we distinguish between those - the formal approved high level technical reports etc. and these are the EO training materials or however we phrase it
Shawn: EO goes through approval - same as a note for most documents. Wasn't proposing that we state it anywhere, just as a means to explaining it to the person who made the comment
Shadi: comments were regarding normative vs non-normative. We should be careful that it is clear where it is linking to, to give the reader a choice to read now or later. I can continue reading the document and come back to it later. I don't want to focus on what type of a document the link refers to.
Shadi: take that as a staff issue for further discussion. Also language used - should/must. 2 types of documents - working group notes and recommendations
sahdi: working group note - no use of must/shall - only informative
shawn; group input
Ian: the title of the document is conformance - if you want to use that type of idea - that complicates the use of must/shall.
Shadi: there is a push to make this a normative document. We don't want anything to compete with WCAG. WCAG-EM is a way of checking how your website conforms to WCAG. We don't want to confuse the position-makers or the policy-makers.
Ian: you confuse developers that way - the developers already have WCAG
Eric: in the public working draft we have to delete all must, what could we replace them with?
<shawn> EWOG comments: http://www.w3.org/WAI/EO/wiki/WCAG-EM_review
Shadi: the reason why it is called a methodology requirement, we had before requirement. This is the methdology procedure or process.
Eric: all the comments are in a disposition of comments so we know whether they are editorial, who made them, the content of the comment/about/proposes, and our thoughts and final decision. We propose to the group a solution for all comments and a proposed resolution and justification and we discuss that.
Eric: links are put to the commenter's mail and some of them were quite lengthy
Shadi: 2 issues to touch on - first examples matching use cases and only sites after development
Suzette: major example around idea of a university website. From where you defined the audience - need to know who the user is. examples need to use a better defined range that capture the context of the audience. Have been developing a list of use cases.
Shadi: is there more than 1 issue here: examples we provide such as university - and other is that the document language doesn't meet the target audience
Suzette: document aimed at - read list from document.
Shadi: reading further it explains it a bit more - does that cover it?
Suzette: who and what - how do people use it when you say 'conformance testing'
Shadi: in the first list we list audiences, the second we have a bit more of the audience and how they can benefit from the document. One of these comments would be better addressed if we had that in the first list.
clarify in the target audience, not only who the target audience is, but who can benefit from it
Shawn: could that be moved into the overview?
Shadi: no
Shadi: this document can be summarized in the overview document, but I don't think there should be a dependency that you have to have read the overview first
shadi: who is this for, rather than 'target audience' Also comments about what is in this document and what isn't
Shadi: there is not sufficient explanation here
Shadi: it may be difficult for a disability advocate to understand how to use the document. Is it clear that this person would give it to someone?
Eric: we had primary and secondary audiences
Suzette: want people to use it by giving it to someone and asking them to follow the WCAG-EM
Suzette: if you put the advocate's hat on, would you know how to use this document?
Shadi: fits with the earlier discussion about who is this for - in the overview document
Shawn: you shouldn't be required to go somewhere else
Shadi: primary audience is the developer who is evaluating after it is built
Shawn: if you're these other people, find out how else you could use it - in overview
Shadi: examples - when we explain the scope of the website (university librayr - 2.1)
Suzette: wasn't complicated enough
Vivienne: explained purpose of the university library example
Shadi: how should the diagram be changed
Suzette: less worried about you excluding parts, but than expecting that a part may be what you're looking at this time
Shadi: before you get to the diagram is where it explains the types of websites - e.g. small part like a library, or the entire library where you can't exclude any of it
Suzette: needs more explanation in the part before the diagram
Shadi: we might need to clarify this paragraph
Eric: we may need to explain this better - you start reading from the diagram rather than reading the section before the diagram
Suzette: we may need headings to point out the 3 scenarios.
<shadi> [important] The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluatio
<shadi> n through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. {Vicki via Sharron}
Shadi: comment - regarding changing the wording about the restrictive use of the methodology to use after the development of the website
Vicki - you could remove the word 'only' - scope 1.1 2nd paragraph
Shawn: 'focuses on'
Vicki: or take out the word 'only'
Ian: this methodology "Primarily" addresses.
Shadi: emphasis was to say be careful of the limited scope - this is only 1 aspect of evaluation
Ian: we were talking about the overview having this discussion on it - do you want to link back to the overview page?
Shawn: let's see where it is landing with the other documents and coordinating the wording
Shawn: we've got a lot of good positioning on WCAG-EM and suggestions for the task force and things we need to work on with our documents. after lunch let's look at the bigger picture and remind ourselves of the use cases and scenarios. We can discuss as a group what we want to work on next.
scribe; Vicki
<scribe> scribe: Vicki
Summary from hall discussion: .....
Points to retain on webplatform docs: moderation of content may be a concern, knowledge from user community on accessibility is important, people may input incorrect information
Further comments: Watching the pages is important as changes to the wiki may not be correct
<shawn> breif review of Eval Analysis http://www.w3.org/WAI/EO/wiki/Eval_Analysis
Shadi: the reason why it is called a methodology requirement, we had before requirement. This is the methdology procedure or process.
Eric: all the comments are in a disposition of comments so we know whether they are editorial, who made them, the content of the comment/about/proposes, and our thoughts and final decision. We propose to the group a solution for all comments and a proposed resolution and justification and we discuss that.
Eric: links are put to the commenter's mail and some of them were quite lengthy
Shadi: 2 issues to touch on - first examples matching use cases and only sites after development
Suzette: major example around idea of a university website. From where you defined the audience - need to know who the user is. examples need to use a better defined range that capture the context of the audience. Have been developing a list of use cases.
Shadi: is there more than 1 issue here: examples we provide such as university - and other is that the document language doesn't meet the target audience
Suzette: document aimed at - read list from document.
Shadi: reading further it explains it a bit more - does that cover it?
Suzette: who and what - how do people use it when you say 'conformance testing'
Shadi: in the first list we list audiences, the second we have a bit more of the audience and how they can benefit from the document. One of these comments would be better addressed if we had that in the first list.
clarify in the target audience, not only who the target audience is, but who can benefit from it
Shawn: could that be moved into the overview?
Shadi: no
Shadi: this document can be summarized in the overview document, but I don't think there should be a dependency that you have to have read the overview first
shadi: who is this for, rather than 'target audience' Also comments about what is in this document and what isn't
Shadi: there is not sufficient explanation here
Shadi: it may be difficult for a disability advocate to understand how to use the document. Is it clear that this person would give it to someone?
Eric: we had primary and secondary audiences
Suzette: want people to use it by giving it to someone and asking them to follow the WCAG-EM
Suzette: if you put the advocate's hat on, would you know how to use this document?
Shadi: fits with the earlier discussion about who is this for - in the overview document
Shawn: you shouldn't be required to go somewhere else
Shadi: primary audience is the developer who is evaluating after it is built
Shawn: if you're these other people, find out how else you could use it - in overview
Shadi: examples - when we explain the scope of the website (university librayr - 2.1)
Suzette: wasn't complicated enough
Vivienne: explained purpose of the university library example
Shadi: how should the diagram be changed
Suzette: less worried about you excluding parts, but than expecting that a part may be what you're looking at this time
Shadi: before you get to the diagram is where it explains the types of websites - e.g. small part like a library, or the entire library where you can't exclude any of it
Suzette: needs more explanation in the part before the diagram
Shadi: we might need to clarify this paragraph
Eric: we may need to explain this better - you start reading from the diagram rather than reading the section before the diagram
Suzette: we may need headings to point out the 3 scenarios.
<shadi> [important] The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluatio
<shadi> n through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. {Vicki via Sharron}
Shadi: comment - regarding changing the wording about the restrictive use of the methodology to use after the development of the website
Vicki - you could remove the word 'only' - scope 1.1 2nd paragraph
Shawn: 'focuses on'
Vicki: or take out the word 'only'
Ian: this methodology "Primarily" addresses.
Shadi: emphasis was to say be careful of the limited scope - this is only 1 aspect of evaluation
Ian: we were talking about the overview having this discussion on it - do you want to link back to the overview page?
Shawn: let's see where it is landing with the other documents and coordinating the wording
Shawn: we've got a lot of good positioning on WCAG-EM and suggestions for the task force and things we need to work on with our documents. after lunch let's look at the bigger picture and remind ourselves of the use cases and scenarios. We can discuss as a group what we want to work on next.
scribe; Vicki
<scribe> scribe: Vicki
Summary from hall discussion: .....
Points to retain on webplatform docs: moderation of content may be a concern, knowledge from user community on accessibility is important, people may input incorrect information
Further comments: Watching the pages is important as changes to the wiki may not be correct
<shawn> breif review of http://www.w3.org/WAI/EO/wiki/Eval_Analysis
Suzette: Shall we check the scenarios with EM participants to get their feedback?
Shawn: The purpose of this page is for internal planning. EO thoughts on who would go to what documents for what tasks. We may not use the "conform overview" column. EO needs feedback from EM on the use cases.
Vivienne: Something is missing on the researcher who is providing a broad range on evaluation of web sites, i.e. unsollicited kind of things. Something like No. 6 but this is somewhat different from a researcher
Eric and Vivienne: No. 4 is using an automatic tool. Maybe this needs to come out.
Vivienne: We also say the "owner" might use this to commission an evaluation according to the methodology. So they would use it to understand the process and put it in the tender.
Suzette: Similar case to the disability advocate who might hand this off to someone.
Helle: If you do a kind of a benchmark study, would you use this?
Vivienne: The general methodology in general,
maybe not all.
... Sampling can be limited. You can still follow the
methodology and limit according to requirements.
Suzette: What about education? Should this be in scope?
Vivienne: Good idea to include this group. Once WCAG EM is more formal, we shall encourage that this is the methodology
Suzette: To sum up: add research, manager, education scenario, remove the automatic tool.
Eric: It would be good to have as a support for processes e.g. in large organizations
Shawn: It would be good to look at the use cases now, evaluate throughout design and development process
Suzette: No. 2 is about the user testing done
by some disability organizations, eg Ability net, Shawn trust
etc.
... This group is important because they are actually using the
assistive technologies
Shawn: No. 3 is the developer, No. 4 is specifically about the person who lands on WCAG EM and who needs to find the right material.
Ian: Something covered by the redesign e.g.
new and discrete (standalone) features, i.e., not to evaluate
the whole site but new features
... A combination of IA/UX process. This could go into No. 4 as
just an addition of new resources/features for an existing
site
Shawn: E.g. I need something for the new cool stuff I am developing now.
Helle: What is the real difference between a new design and a redesign?
Aurelien: Just depends, you might use the same CMS, might be graphical etc.
Suzette: Might be just a few pages adding a
bit on or replacing a part of the site.
... Thinking about the use cases is a good tool for us to work
on the material
Shawn: Our concern was did we have the right type of scenarios.
<scribe> ACTION: Suzette, update EVAL analysis table http://www.w3.org/WAI/EO/wiki/Eval_Analysis with notes from F2F [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action01]
<trackbot> Sorry, couldn't find Suzette,. You can review and register nicknames at <http://www.w3.org/WAI/EO/track/users>.
<scribe> ACTION: Suzette update EVAL analysis table http://www.w3.org/WAI/EO/wiki/Eval_Analysis with notes from F2F [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action02]
<trackbot> Created ACTION-224 - Update EVAL analysis table http://www.w3.org/WAI/EO/wiki/Eval_Analysis with notes from F2F [on Suzette Keith - due 2012-11-08].
<Suzette2> **EDIT TABLE** RE EM: Add research, education, website owner (& advcate) scenarios, delete user of automatic tool
<Suzette2> ** EDIT TABLE** RE DESIGN New discrete features/functions, new content - design/development
<shawn> aka / Eval in Process
<shawn> http://www.w3.org/WAI/EO/wiki/Eval_in_process
Shawn: What we have now is some basic material
and also a link to related info on the WAI site. Let's take a
few minutes to re-read and brainstorm.
... What are the thoughts, focus on this document Eval in
Process?
Helle: Who is the audience?
Shawn: From the previous table
Ian: Multiple audiences who may want to read a bit which is relevant to them so do we separate into multiple pages with a common intro?
Aurelie: I agree. A full document will be huge. As a designer, I need to know what is relevant to me, a small document with specifications for the process
<shawn> Vicki: like having it by different groups
Shawn: We need to think about : is this 5 or 25 printed pages?
Suzette: 4 pages. It would be nice to start with four pages and go from there.
Aurelie: The problem is that the current material is not written in an understandable way. For a designer, the technical specifications are too difficult. A designer needs something short to focus on.
Shawn: We can't go to that level of guidance. It may be needed. It's a process outline.
<shawn> Suzette & Vicki: we are missing the how to do X
Suzette and Vicki: But that could be missing. Maybe it's for the webplatform.doc
Vivienne: The only thing I see missing besides the basic categories, under the Project Planning Stage, decide whether you have the necessary skills inside or nor, whether to do it internal or external, in order to decide right at the beginning to determine the resources. It's part of the budget planning.
Shawn: It's actually under Project Budget and Planning
Ian: What about the content?
<scribe> Scribe: Vicki
http://www.w3.org/WAI/EO/wiki/Eval_in_process
Shawn: What kind of size of pages are we talking about?
Ian: We have some information on project planning, nothing on design, content. Until I know what the content will look, it's hard for me to structure. For development, it's a very iterative process. I don't know whether we say the same for project planning. Just would like to flash out what would go in those areas.
Suzette: Sharon has been very keen on having a section on design which covers the early stages, e.g. wire frames, specifications, that could be seen as a step in the development process. We sometimes put design and development together...
Ian: What I've put in already is what a
developer might need. We need something to guide the designers
but don't know what the scope is.
... The idea is e.g. we as developers just get a design and
need to code it. They don't know the color contrast etc.
Vicki: There are separate roles between the designer and developer
<IanPouncey> vicki: Designers don't always no the tools, they are willing but need to know the requirements. They produce the design, that goes to the developer and that becomes a prototype.
<IanPouncey> Vicki: There is so much outsourcing, sometimes design companies don't know.
<IanPouncey> Vicki: Maybe we can use our link with web platform, and point to web platform for specific things like choice of colour. These are things that change with technology, tools, etc.
Shawn: Points to uiaccess and the page on design issues. A lot of people don't realize that they can test prototypes for accessibility. Ian, what about what is on the page as regards development, how much is covered?
Ian: This is my development cycle. It works for me. I think developers need something like this. They just want to know what to do.
Vicki: I agree, something short and simple and to the point
Ian: Most developers will have their own cycle which may miss out the accessibility bits. Perhaps, a different approach would be to pull out the accessibility tests and let them do what they want.
Shawn: My question is what do we say here and what do we say in the "Quick checks"?
Ian: This is a type of quick check which I do and test.
<shawn> Vicki: Like short, concise list. Not paragrpahs (like some other places)
Helle: Our developers really like to use definition lists instead of using headings and that can be a problem for a colleague who is a screen reader user. I think that we would need somethings about recommended practices.
Ian: In html5, the use of definition list has been broadened a lot but whether ATs will catch up or not, who knows.
Helle: We use definition lists for announcing new publications.
Shawn: People like it because it is formatted
nicely but you don't get headings.
... This goes back to our preliminary checks. We've already
said that headings are very important. How much guidance should
we provide.
Suzette: We haven't discussed what it is we want to communicate to the reader of the web page. To my mind, it would help . You need to plan e.g. a railway timetable, or is it going to be interactive. If you're thinking about that, what are the different options, what is the best option for me. What is the communciation goal.
<Suzette2> ACTION: Suzette Define communication goals, eg traditional prose with heading, bulleted lists, table or interactive query etc [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action03]
<trackbot> Created ACTION-225 - Define communication goals, eg traditional prose with heading, bulleted lists, table or interactive query etc [on Suzette Keith - due 2012-11-08].
Ian: What also helps is the paper user testing. From the other side, using a screen reader helps with document structure but really whether you need testing with users. There is so far you can go as a developer or designer.
Helle: I think that you have designers or developers who do not have enough knowledge, they find it more fancy to do it one way or another, which might not be accessible at all.
<shawn> ACTION-225 = Define communication goals, eg traditional prose with heading, bulleted lists, table or interactive -- add to <http://www.w3.org/WAI/EO/wiki/Eval_in_process>
<shawn> ACTION 225 = Define communication goals, eg traditional prose with heading, bulleted lists, table or interactive -- add to <http://www.w3.org/WAI/EO/wiki/Eval_in_process>
<trackbot> Sorry, couldn't find 225. You can review and register nicknames at <http://www.w3.org/WAI/EO/track/users>.
Ian: There is no definite idea what usability is in particular.
<shawn> ACTION-225 is Define communication goals, eg traditional prose with heading, bulleted lists, table or interactive -- add to <http://www.w3.org/WAI/EO/wiki/Eval_in_process>
<IanPouncey> Vicki: Sylvie was telling me that she gives training on how content can be made accessible
Shawn: We need to decide how much guidance do we provide?
Sylvie: The courses are sometimes a day, maybe longer, how to design accessible documents.
Shawn: Have you done early evaluations on prototypes?
Sylvie: Sometimes. We needed to provide a cost estimate to find out how much it would cost for the future application and the only thing we could do was to look at the contrast to see if it passed and to evaluate how much time it would take, how many functionalities. It is really difficult to ask for evaluation at the beginning. Often, it happens at the end and it's too late because web accessibility has not been taken into account.
Suzette: We need non-visual dependent ways of analysing concepts. When Sharon put up her lists, I thought that they were all visual but if you actually want to portray the structure of the site, you can do that through story telling, walk throughs and something that a blind person can relate it.
Sylvie: You cannot only rely on one type of disability.
Shawn: A design walk through using a screen reader can only be done by someone who knows.
Suzette: When people contribute to providing a link, they don't know how to describe the link and it's simple information that they need to know.
Shawn: Ideally, someone who would know how a screen reader interacts, someone who would program the paper prototype for a screen reader but how many people have that knowledge.
Suzette: Probably, the most useful thing would be to discuss the concepts, processes and structures. Is that too much usability rather than accessibility.
Shawn: The big challenge is to define what is ideal. How do we encourage people to do a bit more than they are doing now?
Suzette: If we want to move accessibility up the design phase, then, maybe we have to put these down for guidance.
Helle: I was looking at the development stage of the document, would we put in something as to why things are relevant.
<IanPouncey> Vicki: I work with a lot of developers, and often their attitude is that I want it to be accessible, just tell me what to do, and don't want to know why
Ian: I suppose we could put in some short paragraphs to pull out those points. We wouldn't want too much detail.
Helle: I would put in why because sometimes they ask why
<IanPouncey> Vicki: We could link to the relevant section in WCAG techniques
Shawn: There are places we can point to.
<shawn> <http://www.w3.org/WAI/intro/people-use-web/principles>
Shawn: We could point people to the "Accessibility Principles" - How People with Disabilities use the web .
Suzette: Some of the questions I'm thinking about are defining the users and the communication requirements.
<shawn> [ walkthough <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Current_related_WAI_information>]
Vivienne: Some of these things I'm seeing now, I've not seen a lot of this. This should probably be a concern because I'm not pointing my student to it. Maybe some kind of a site map.
Shawn: If you go to the "Discover new
resources... " on the left. Follow that link and let me have
your feedback. We took a few steps in this area to
improve.
... We have also started a number of promotional campaigns
since last year.
... So, do we need a document or do we refine what we already
have?
... Let's go back and look at the use cases and remind
ourselves who needs this document. Example, I get this
document, I'm a manager for subsite, so what do I do right
now.
Ian: In the Business Case for Accessibility, we talked about the cost benefits.
Shawn: Were you talking about this document and decreasing costs?
Ian: We talked about the general case and the
cost at quite some length. This is important for
managers.
... I don't think we have anything equivalent that would talk
to designers, developers, content writers
Shawn: There's a section on "More Efficient Development" in the document
<shawn> <http://www.w3.org/WAI/users/involving#why>
<IanPouncey> Vicki: Would the list of development workflow go in this document or web platform
Shawn: We'll see how the document
develops
... Let's have a round of thoughts on this new document.
Helle: I think it's good if we could look into what we have already. The idea about the document is relevant. I think we should do it.
Suzette: I think having a process document is good. I think we should have reached the point as to what the development process is. There ought to be some literature.
Shawn: This gets back what do we want to do. Is the purpose about involving users? We want to give a broad overview and point to some information.
Suzette: The UK standard is a 16-step process.
Helle: It's difficult to follow those steps
Sylvie: I think about France and there are difficulties to address accessibility problems. There is a French charter on this and some recommendations on how to go about this. I can take an action item and see if I can summarize this.
<Suzette2> Uk Standard is BS8878
<IanPouncey> Vicki: I think the document is taking place. I like it. I think there is lots of documents that we can reuse. I think it will have a lot more value. If we can put in a few bullet points for each stage that would be helpful
<Sylvie> ACTION: sylvie summarise for the group the internet charter and recommendations of the French government on developing web sites as an input to early stage doucment [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action04]
<trackbot> Created ACTION-226 - Summarise for the group the internet charter and recommendations of the French government on developing web sites as an input to early stage doucment [on Sylvie Duchateau - due 2012-11-08].
<IanPouncey> Vicki: we should have a little bit of how.
Ian: The use I have for this document is to give it to the designers, the product developers, the other people involved so that they understand they need to implement accessibility but they don't know what it means so that there is not too much detail but it links to as many other documents as possible.
Vivienne: Looks very interesting.
Helle: I have just looked at some of my colleagues documents and see if we can use some of it.
Shawn: Who wants to take a stab at it?
<scribe> ACTION: Ian and Vicki going to work on parts together [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action05]
<trackbot> Created ACTION-227 - And Vicki going to work on parts together [on Ian Pouncey - due 2012-11-08].
<hbj> ACTION: hbj summarise to the group some Danish recommendations re. how to make sure your new web site is accessible [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action06]
<trackbot> Sorry, couldn't find hbj. You can review and register nicknames at <http://www.w3.org/WAI/EO/track/users>.
<scribe> ACTION: Ian and Vicki goint to work on the document "Eval in process" http://www.w3.org/WAI/EO/wiki/Eval_in_process#Current_related_WAI_information%3E and come up with a first draft [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action07]
<trackbot> Created ACTION-228 - And Vicki goint to work on the document "Eval in process" http://www.w3.org/WAI/EO/wiki/Eval_in_process#Current_related_WAI_information%3E and come up with a first draft [on Ian Pouncey - due 2012-11-08].
<hbj> ACTION: Helle summarise to the group some Danish recommendations re. how to make sure your new web site is accessible [recorded in http://www.w3.org/2012/11/01-eo-minutes.html#action08]
<trackbot> Created ACTION-229 - Summarise to the group some Danish recommendations re. how to make sure your new web site is accessible [on Helle Bjarnø - due 2012-11-08].
<shawn> rrsagent drop action 227
<shawn> trackbot, close action 227
<trackbot> Sorry, shawn, I don't understand 'trackbot, close action 227'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.
<shawn> close action-227
<trackbot> Sorry... closing ACTION-227 failed, please let sysreq know about it
<shawn> http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation
Shawn: Reminder that we have an old Preliminary Evaluation from 2005, In the wiki page, you can see where the edits were and where they are now archived.
Sylvie: What is wrong with the old preliminary page?
Shawn: Would you today, test in the way it is
outlined in the document? Well, the way we do things today is
different. E.g. to check images today, the easiest way would be
to use WAVE.
... The approach for this document was to put in the structure
and fill in after.
... Having a look at Wayne's list. Not too sure the order of
the check.
... This document contains currently input from a variety of
sources. It is just a draft, not refined.
Suzette: Maybe it needs to be tied back to the Success Criteria. Not too sure whether they are A, AA . I wonder if it matters or not but it seems important to have a reference back.
Shawn: We could point to "BAD" and also the "Accessibility Principles".
Suzette: I was trying to some of Wayne's list back to the Success Criteria and I found some difficulty in doing so.
Shawn: Any thoughts on this.
Ian: Let's go through the list on this page and see whether we can combine the lists into one.
Sylvie: Why not do a brainstorm like two years ago?
Vivienne: What is the main goal? How many levels are you doing here? Some of these things seem reasonably technical.
Suzette: A list without having special tools and special technical knowledge.
Shawn: Something that an average person could
do.
... We're trying to match the list to the use cases chart.
RRSAgent draft minutes