See also: IRC log
Eric: states no further questions about questionnaires so far
Eric. Questionnaire 4 will be lengthy, 16-20 questions
Eric: use holiday to look over it
Eric: item ID6 / ID7 "Definition of website part"
Eric: Shadi sent a new text proposal (reads it out)
Eric: asks if there is agreement on the proposal by Shadi
<ericvelleman> # DoC ID 6 (wrongly named 7 in earlier discussion)â€“ Definition of â€śwebsite partâ€ť
<ericvelleman> Resolution: Change to: â€śA set of web pages within a website that together provide common use or functionality. In some cases website parts may have their own design, navigation, and web addresses. In some cases website parts may not be directly managed by the website owners.â€ť
<Sarah_Swierenga> +1 common use or functionality
<Kathy> +1 - common use may need further definition
Shadi: extra paragraph may make definition a bit too long
<Sarah_Swierenga> i like keeping the extra paragraph with examples here
Eric: consider options for moving it
... anyone disagrees? Seems not...
Peter: Consider how that would play in the context of a web application
Shadi: no immediate answer - for the context in
which it is being used it mighr be OK - may be not ideal for web apps so we
would need a way to map "wep page" on the context of web apps
... what issues do you see, Peter? Website part may resemble website area - web apps more difficult to separate..
Peter: Difficult to give an example for part of web app that shares the same URL - no immeadiate example
Eric: keep in mind for future work
Kathy: example - we may need to define what
comman usages for web aps are ok
... Example of components brought onto other pages, but avaliable also elsewhere - gets more difficult in web apps
... Some of that might need to be reviewed separately
Shadi: Does the issue also affect the definirtion of 'web site'?
Moe: How would a portlet be defined - not a web page, more a self contained unit embedded on pages - test teams have difficult to define responsibilities, differentiate between container and portlet content
Shadi: Reason to define website parts is really
to support selectino of scope on evaluation
... If evaluation of portal is the aim, all associated components would need to be included in that.
... so the context is embedded / aggregate content - is that what you are after?
Moe: Portlets get developed on its own - often a lack of communication between responsibilities for portlet and containing site
Kathy: for apps there is the framework and then the content - is there a waay to incorporate the distinctino between both?
Shadi: From the perspective of the claim: if you
focus on just one aspect such as a portal that is fine, but if you want to make
a claim about the application all other things need to be included
... the question os if we do partial evaluatinos, can tzhe be aggregsated if al is covered?
kathy: in educatonal framework, you have one frame for courses and then individual courses / content - woudl make sense to be able to evaluate the tow independently (for efficientcy)
Shadi: You probably would not be able to separate
... If the framework was evaluated at the outset, what else do I need to evaluate in addtion? WCAG-EM probably does not cove rthat (yet?)
Peter: Core of the challenge is "set of pages
within the website" - may be change to change to area within website
... in an ideal scenario you may have a course that may not excersise all aspects defined in the framework - a dummy aplication may, however, to be tested comprehensively
... so ypu may not need to review every course individually, but there are issues, of course
Shadi: wondering if an evaluator would need to
populate dummy content - its probably a different discussion. If you want to
evauate a specific courseware, a general statement such as "framework proven
accessible" would not been sufficient
... will revise definition to addres web application issues
Eric: thinks definition is already wel received and may stay weit han additional editor note about the issues raised?
Shadi: add note about applicability tzo web apps,
portals etc - refers to WCAG2ICT that looks at extending WCAG tzo non-web
... will think about note on web apps, aggregated content, would appreciate input from others via list
Eric: will come up later, too
<shadi> ACTION: shadi to look at refining updated definition of "website part" [recorded in http://www.w3.org/2012/07/05-eval-irc]
<trackbot> Created ACTION-3 - Look at refining updated definition of "website part" [on Shadi Abou-Zahra - due 2012-07-12].
Detlev: Peter, Moe Kathy may provide input how WCAG-EM might be modified to bve useful for evaluating weeb aps
Eric: separate issue from comments we are
... Good to start that discussion on the lisdt
Peter: will attempt to review and add input - many othe rburning issues so not much time righ rtnow for that
Kathy: happy to add to that discussion (reg, Portlet evaluation etc)
Was tzhat Moe makinh the statement earlier that she is happy to contribute tzo discussion on portlet evaluation?
Eric: closed with remark that it will be addressed later
Eric ID8: user involvement - no change to proposed resolution
<shadi> [[The clarity is already provided in this section. Involving users is optional, but is strongly recommended. The section provides a link to the W3C/WAI evaluation suite for more explanation.]]
Shadi: Different rationale in questionnaire, more appropriate and better thsan current resolution
Peter: Agrees that there is enough in the draft
Peter: What was meant was it is not necessary to get back to reviewer specifically - just point to futurwe discussion ahead..
Hope that nails it, Peter?
<ericvelleman> DoC ID 9 - implicit/interpretable-from-reading
Eric: ID9 Resolution that secton will need to be rewritten
<ericvelleman> New Proposed Resolution: We will need to rewrite this section to avoid misconceptions New Rationale: What we meant is the primary target audience and the context of use (public website vs intranet etc.). This section needs to be rewritten to avoid these misconceptions that have occurred.
Eric: has updated resolution with input from Shadi in questionnaire
Shadi: we cannot close this issue before updating the section
Eric: rewrite in sepatrate documents and then disucssion makes process quite complex
Shadi: Reply to commenter is: will be adressed in next version
Eric: Q is can we keep things opein in Disosition of comments and clos in issue list?
Shadi: Up to you Eric
<shadi> +1 to Peter's suggestion
Peter: Process comment: given the many difficult parts it would be helpfulĂ¶ to include hyperlinks to sections within draft
Eric: ID 10 - Unstable techniques
Eric: comments suggest no change
... this should be addressed by WCAG WG, not our issue, but not clear for every one
<ericvelleman> Proposed Resolution: We may not be able to address this issue in the next draft but will add in the editor note for section 3.4 that says: â€śEvalTF will attempt to provide clearer guidance on using Sufficient/Failure Techniques in practice in later draftsâ€ť. Also we will start a dialog with WCAG WG on this issue.
Eric: Editor note on advice using Sufficient Techniques in later drafts
Reaction to that?
Shadi: (looks at editor draft) - Eric strated filling out the section
<Sarah_Swierenga> we want to close comments too!
Eric: put in editor note, code comment
Shadi: Response to commenter could be yes being
considered in upcoming draft
... Detlev's statements for next questionnairw
Eric: everyone agrees with closing comment
Shadi: Best process: Identify what evaluator
needs, and get WCAG WG to update information on that
... we can collect what the issues are, and provide input to WCAG WG
Eric: change made, comment closed
IÂ´ll be on vacation too
Eric: give more time for next questionnaire over the next two weeks
Next meeting in three weeks (Thursday of 26 of July)
Lets have discussion on the list
Eric: will provide new editor draft a few days
before 26. July
... thanks everyone, closes call