See also: IRC log
<trackbot> Date: 24 October 2014
<scribe> Scribe: Sharron
<yatil> As stated in the wiki, the lead sentence is too broad. Suggest something like "Forms are commonly used to provide user interaction on web sites and web applications."
Eric: We got a little bit of feedback, mostly minor points and wanted to look at those:
<yatil> Before: http://www.w3.org/WAI/EO/Drafts/tutorials/forms/
<yatil> Forms are used to provide functionality in websites and web applications.
<yatil> After: Forms are commonly used to provide user interaction in websites and web applications.
Paul: Second on is better
<Sharrone> AnnaBelle: +1
<Sylvie> I like the second proposal better.
Shawn: Any objections to that
change?
... next?
Eric: Andrew commented
<shawn> Tips and Tricks page - suggest adding some examples of icons that are commonly used, Also suggest adding a tip about testing (with a list of common keystrokes)
<yatil> http://w3c.github.io/wai-tutorials/navigation/tips/
Eric: The question since it is somewhat empty is what to do with the Tips and Tricks. Do we want to do what Andrew is suggesting or if not, need to think aobut the section as a whole
Shawn: There is now one bullet on the Tips and Tricks, Andrew's comment relates to that?
Eric: Yes because what he is suggesting would go there. Otherwise we could put the single bullet somewhere else and omit the Tip and tricks page
Shawn: So Andrew's comment -
showing related icons - is relevant to that.
... show an example of an icon that links off of the current
site. Any objections?
RESOLUTION: Add example icons
Shawn: Next point was to add a tip about testing with a list of common keystrokes. Is that a clear suggestion Eric or do you need more detail?
Eric: I am not sure if that is in
the scope of the tutorials. The same keystrokes to do testing
would apply to other tutorial topics, not just to this.
... what we could do is to tell people they should test and
give them a link to that section of EasyChecks
Sharron: +1
Shawn: But does that not apply as well to all?
Wayne: Yes but I think that
keyboard testing for forms deserves a section of its own.
... keyboard testing for menues
... soemthing to refer people to is the widget section of the
ARIA Authoring Best Practices
... this is not for the faint of heart or flat beginners.
Shawn: Remind me of what is covered in the rest of this tutorial?
Eric: We cover the fact that people navigate from the keyboard but it is decoupled from the specific sub topics
Shawn: So the question is what to say about testing throughout the tutorials and to consider adding links to EasyChecks in all or to discuss in Tips and triacks or to put on a wish list for later.
Wayne: We were not able to do keyboard testing in depth in EasyChecks. Remember we had to cut down the forms section in EasyChecks in respect for the fact that it was meant to be "Easy"
Shawn: So what about the fact that the tutorials are meant to be a guide to doing it, not a testing and validation - look elsewhere for that.
<shawn> link to http://www.w3.org/WAI/eval/preliminary.html#interaction ?
AnnaBelle: As a developer, I really need guidance for how to make sure and validate to myself that I am doing it correctly.
<Wayne> http://www.w3.org/TR/wai-aria-practices/#kbd_general_ex
Shawn: What about EasyChecks as a resource for that?
AnnaBelle: It is OK but seems like an interim solution
<Sylvie> Agree with Anna Belle that this is an interim solution. May be add a longer explanation on a wish list. Because you have all shorcuts with ARIA that are not the same.
Shawn: There are these things on the table: First would be to put on a wish list - put on menues turoial and perhaps others a guide to testing. It might include an EasyCheck, maybe point to ARIA practices, maybe have an entire separate page within the tutorial for testing.
Wayne: ARIA Practices are way over in Difficult land and Easy Checks are way over in Easy land and we probably need a median solution that at least gives developers an expectation of what behaviors they should look for. For example, the up and down arrow keys are overloaded in the screen readers and do not behave as a developer might expect.
Shawn: One aspect is how to design it - and that belongs solidly in the tutorial - and another aspect is how to test. That is the question. Eric can you write up a wish list item with some of these ideas.
Sharron: Is the point of the wish list to say that we are tabling the testing guidance?
Shawn: Yes
<Sylvie> +1 to at least add links to easy checks and ARIA best practices
Sharron: But I think even a link to easyChecks would be useful on some of these more complex items
AnnaBelle: Yes I don't feel like I need it for many things, but for menues/navigation I REALLY felt like I needed some confirmation that I did it right
Shawn: So what if we say we add a link to the EasyChecks...and what about a link to the ARIA proactices?
Wayne: I can provide that link.
<metzessive> Second Sylvie's comment
Shawn: Eric how do you feel about that?
Eric: I am not sure. Linking to EasyChecks is good but linking to the ARIA stuff is problematic.
Wayne: I agree that it seems like a hostile environment.
<yatil> http://www.w3.org/WAI/EO/Drafts/tutorials/navigation/flyout/#web-application-menus
<Wayne> then easy checks is best
<yatil> +1
Shawn: Current proposal is to add a link to Easy Checks in the Menues tutorial
<metzessive> +1
Sharron: +1
<AnnaBelle> +1
<Wayne> +1
<paulschantz> +1
<shawn> http://www.w3.org/WAI/eval/preliminary.html#forms
<yatil> +1
Shawn: In the forms tutorial we also have an EasyChecks section, so a similar proposal is to add that link within the Forms tutorial
<metzessive> +1
Sharron: +1
<paulschantz> +1
<Sylvie> +1
<Wayne> +1
<AnnaBelle> +1
<shawn> s/Easy Checks in the Menues turtorial/Easy Checks in the Menues turtorial http://www.w3.org/WAI/eval/preliminary.html#interaction
Shawn: Next comment is from WCAG-WG
<Wayne> http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget
Eric: It is about the menues tutorial as well. They think that the current navigation.menues tutorial is trying to cover two topics in one. They suggest to separate the two into individual tutorials.
<metzessive> Where can I find those?
Shawn: Let's take a quick reading break to look
<yatil> https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#25_October_2014_Teleconference_Agenda
<metzessive> Thanks
<yatil> [[I can't quite put my finger on what I'm uncomfortable with in this tutorial. I think that it perhaps has to do with the way that "menu" and "navigation" seem to be intertwined in some ways but regarded as different in others. ]]
<yatil> [[It needs to be made clear right up front that there are 2 entirely different concepts being discussed in the section. Firstly we have the 'old-school' web site navigation mechanisms. Secondly, we have the new WAI-ARIA application menus. These are entirely different concepts and should be introduced up front rather than just dropping the aria menus into the last page.]]
<yatil> [[I think what we are really talking about here is navigation structures and not menus. Menus a very specific type of navigation structure that has specific accessibility API roles such as those defined in ARIA and has specific keyboard patterns associated with it. When you may statements that screen reader users expect menus to work like those in stand alone applications this statement speaks to something different from what the main content of the article is
<yatil> about -- it speaks to real menus as I indicate above. If we want to go the route of actual menus then we need to include SC 4.1.2.
<yatil> At this point I think the tutorial should be about navigation and we could then have a section specifically about menus and discuss the above.]]
<yatil> http://w3c.github.io/wai-tutorials/navigation/
Eric: Originally I envisioned this tutorial as a navigation tutorial. Shadi suggested to add info about application menus. I thought we had made good distinction. They seem closely realted but turn out to be quite differnt. I am not sure there enough for a separate tutorial for application menues
Shawn: is there anything that oddurs to you to make the distinction stronger withn one tutorial?
Eric: Yes I tried to describe it better and have made more distinctions between the two. I would prefer to leave it in.
Sharron: Is the next step to send back to WCAG?
Shawn: No we need to look at it more carefully in EO. Eric can you craft a reply to WCAG and summarize what you ahve done (even point to previous drafts that highlight the changes that address WCAG's comments.) Then EO can review and determine if this meets their comment guidance.
<yatil> http://w3c.github.io/wai-eval-tools/
Shawn: Jon's comment was to move the disclaimer to the top or otherwise handled to avoid looking like an endorsement
<paulschantz> I agree
<Sylvie> I agree that it would be easier when it could be placed at the top.
AnnaBelle: I think the position of the disclaimer is OK I looked for it in the footer.
Shawn: Two points: Not endorsing vendor products is a BIG deal...a foundational principle of W3C. So coming here and finding a list of tools is a giant departure. it needs to be prominent and easily found.
AnnaBelle: If that is the case, I understand but I would suggest that the disclaimer also belongs in the footer where people look for it.
<paulschantz> Is the list moderated?
<yatil> List is semi-moderated, Paul.
Jon: My attention was drawn to the blue, there are superlatives that imply that the W3C has an opinion about the tools. But then on further exploration I find the fact that people submit their own and the superlatives are submitted by the tool maker.
Shawn: We need to record as an issue for alter - do we have parameters in the submission process that filter the superlatives? do we have limits on how they make claims?
Eric: OK I will
<metzessive> "Information in this database (including the search criteria) reflects claims made by tool developers, vendors, or users;"
<metzessive> from the disclaimer
Shawn: Another point is that the W3C does not endorse vendors and the second point is that the listing text itself is not written by us. So perhaps pulling together AnnaBelle's comment about the disclaimer itself needs to be made more clearly as well as the fact that the text is not ours.
<Wayne> Shawn's idea is more to the point.
Shawn: So imagine that the disclaimer is down at the bottom. So if we move it to the top, what points would be made? One is wee do not endorse, what else?
<shawn> Sharron: .. important that this is text submitted by the vendor
<paulschantz> is a list of vendors & products like this unique on the W3C site, or is this a new thing?
Sharron: Good call Jon, we need this. Add the fact that it is vendor generated
Shawn: A proposal is to put an introductory sentence and perhaps change the link from "Disclaimer"
Wayne: But have both - the disclaimer as well as the introductory text
<AnnaBelle> -1
<Wayne> +1
Shawn: So the proposal is to have introductory text with the two points, as well as a link to what is now disclaimer but renamed
AnnaBelle: It is important to use the word disclaimer somewhere because that is exactly waht it is.
Sharron: For example in the footer?
<Sylvie> A disclaimer in the footer would not be read. I think it is important to inform the reader at the beginning of the doc.
<paulschantz> Maybe ask the W3C lawyer what's best for disclaimer text...?
Shawn: The main information would be in the lead-in text but the word "disclaimer" would show up in the footer and link it?
Eric: I am confused
Shawn: AnnaBelle, if we have a footer link that says for disclaimer info see above, would that work?
AnnaBelle: I am not sure, I realize I am confused as well
Shawn: OK we will go offline and develop a specifc proposal to bring back to the group.
<paulschantz> I agree
All: Sounds good
Shawn: we had the surveys out, several replied. Jon you sent copy edits but approved the draft status, is that what you emant to do?
Jon: Yes I had suggestions but they were not meant to hold up the progress
Shawn: OK then Kevin will address
your comments in coming weeks
... we may not get to them in the F2F but soon after. Any other
comments about posting draft documents?
... we did the quick fixes for posting the drafts but will put
out a schedule for addressing the other tools and tutorials at
a more reasonable pace.
<shawn> http://www.w3.org/WAI/EO/2014/10f2f
<Wayne> http://www.w3.org/TR/wai-aria-practices/#menu
Shawn: So drafts of many new things have been posted. Will publish as schedule for refinng and polishing those. At the F2F we are going to kick off some new work, some of which has been on wish lists since 2008 and that we now have resources for.
ready for discussion
<paulschantz> ready
Shawn: we will have a
teleconference line. If anyone is able to join by phone, you
are welcome
... Any general comments?
... let's then look at a couple of specific. First is quick
ref
<shawn> https://www.w3.org/WAI/GL/wiki/Resource_Redesign/Quickref/Analysis
Shawn: Background is that we had
worked on this a few years ago for the doc that is called "How
to Meet..." with quick reference in sub title. We had worked on
ideas for making it more interactive and more useful. Since we
have the resources, we are looking at how to implement that
idea.
... you may recall that the WCAG-WG has also has renewed
interest in the technical support docs, so tehy will join us
for the analysis of what that document might be. The goal today
is to give participants a way to review, get familiar, offer
suggestions for our discussion with WCAG-WG. Especially
interested in getting input from those who will NOT be
there.
AnnaBelle: I would love to include the idea of flowcharts, illustrations and some sort of complementary illustrative guidance to the new document
<yatil> http://www.w3.org/WAI/WCAG20/quickref/
Shawn: AnnaBelle, looking at the exisiting QuickRef, please say a bit more about what you are thinking.
AnnaBelle: This is very boxy, very linear. I am not prepared right now to get into the specifics. Was thinking more about an earlier discussion we had about...
Kevin: It was ageneral discussion about using illustrations and imagery to tie things together
<shawn> Sharron: [@@ people like illustraations in Easy Checks ... imagry in other places ... to distrupt wall of text]
Sharron: In their preliminary discussions, AB, Jon, and Kevin discussed the importance of how illustrations can support different learning styles, et
AnnaBelle: Yes that would be very useful to me
Kevin: And to provide an alternative for the stock photos that were proposed
<shawn> fyi, arrows about the docs http://www.w3.org/WAI/intro/wcag20
AnnaBelle: Can we share the pictograph?
Shawn: Maybe later at the
F2F
... is that about WCAG documents?
AnnaBelle: I will email it
Shawn: At the joint meeting with
WCAG-WG we may or may not have a phone, depending on what room
we are in
... main outcome is that we establish good joint relationship
to work together going forward. We need to do more joint work
together so establishing that good natured collegial
relationship is high on the list of priorities.
... WCAG chairs will be leading our combined meeting time, so
they will define the specific agenda. So we want them to leave
finding that we can provide useful input.
... that we are a support not an impediment
... I know there is a lot here and I wanted to give everyone a
chance to review and prepare.
<shawn> https://www.w3.org/WAI/EO/wiki/Easy_DD
<AnnaBelle> very excited to see "Easy Design & Development Analysis" coming to table again!
Shawn: When we did EasyChecks, we
wanted to do a similar document for developers, designers, PMs
etc
... Sharron, AB, Liam, Howard and others in the group
brainstormed about what those might look like
... May end up spending a fair amount of time on these on Day
1. Anyone want to contribute and help get us primed for
thinking aobut that?
<shawn> Sharron: one of the motivations was enthusiastic embracing of Easy Checks from people
<shawn> ... community repsonse to Easy Checks so overwhelming positive
Shawn: What thoughts about how to organize the QuickStart Guides...by role, coders, vs designers etc?
Jon: What do you mean by coder?
Shawn: I want it to be entirely open, however people want to define it?
AnnaBelle: Job descriptions are a bit more stable than it used to be but still job responsibilities are fluid. One useful term is "front-end" vs "back-end" "graphic designer" seems more useful than "designer"
<shawn> front-end web developer
Shawn: So if we were develop "Quick Start Gudies" would we have just the two - front end developer and graphic designer?
Paul: There are more than just two...the front end area itself is different that tne graphic designer. Those who can do the entire full stack for the front-end are rare birds. S
Shawn: So would there be more than 2? what would those be?
Jon: I see a different situation for roles. They are often vague and often overlap.
Shawn: Don't need to talk about job descriptions, more focused on what would be useful and what would group well for knowledge transfer about accessibility?
<AnnaBelle> I vote for 2 groups
<paulschantz> nearly every "hard core developer" I've ever met viewed the "code" we talk about in the accessibility community as pure front-end coding
<shawn> eric - not "roles" but "tasks"
Eric: I have a hard time to draw the line between developers and designers. What do I look at if I m looking at HTML? What do I llok at if I am workign on graphic design? Being task specific rather than job specific.
Sharron: +1
<metzessive> that's really interesting, Paul. Almost all the developers with programming backgrounds view what Designers do as "art" and not coding at all.
<paulschantz> front-end coding on larger teams are split between designers who focus on pure look and feel, interaction designers who focus on DOM and Javascript, and API developers who code hooks to back-end systems
Kevin: I would go with that idea. The concept of a front-end developer is fairly well established but covers quite a number of sins. Graphic design is a task that can be specifically addressed. Top ten planning things would be useful in my opinion. Slightly tangential but can have impact is back end foundation. How is the back end stack put together.
Shawn: Sharron can you say more?
<Zakim> shawn, you wanted to follow up Sharron proj managers
Sharron: PMs need to know how to integrate accessiiblity into the whole project.
Wayne: And to add to what Kevin said - the recent conversation on WAI-IG about headings is a good example of people being stuck with built in back end errors
<shawn> Dynamic guide for planning https://www.w3.org/WAI/EO/wiki/Dynamic_guide_for_planning
Shawn: So far Kevin has been
updating text in planning docs and now we are looking at a more
dynamic way to use these docs and add to them.
... Jon and Kevin (and AB and Sharron) if you took minutes, we
would be interested in being brought into that conversation so
it you have notes to share, now is the time.
AnnaBelle: We had introductory conversation and siad we would reconvene when it was time
Kevin: I do have notes in the
wiki
... will link when I find them
<kevin> https://www.w3.org/WAI/EO/wiki/Planning_illustrations
Shawn: I am excited about the
work coming up. Look forward to seeing everyone and regret
those who cannot join.
... thanks all, see you soon.
<Sylvie> bye
trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/on/one/ Succeeded: s/turtorial/tutorial/ WARNING: Bad s/// command: s/Easy Checks in the Menues turtorial/Easy Checks in the Menues turtorial http://www.w3.org/WAI/eval/preliminary.html#interaction Succeeded: s/ok// Succeeded: s/"nformation/"Information/ Succeeded: s/tot he/to the/ Succeeded: s/soming/coming/ Succeeded: s| /me uh, fairly recent stuff! ;-)|| Succeeded: s|wayne /me Eric, you might look at the keyboard summary in the link above. It is very clear, and represents expected behavior.|| Succeeded: s/Kevinn/Kevin/ Succeeded: s/brainstromed/brainstormed/ Succeeded: s/to ES so/to Easy Checks so/ Succeeded: s/psoitve/positive/ Succeeded: s/ two - front end and back end/ two - front end developer and graphic designer/ Found Scribe: Sharron Inferring ScribeNick: Sharron Default Present: Sharron, AnnaBelle, Shawn, EricE, +33.6.62.33.aaaa, sylvie, Wayne_Dick, kevin, PaulSchantz, +1.202.276.aabb, Jon Present: Sharron AnnaBelle Shawn EricE +33.6.62.33.aaaa sylvie Wayne_Dick kevin PaulSchantz +1.202.276.aabb Jon Regrets: Jan Wayne Vicki Andrew Helle_(Maybe_Sylvie Shadi Jon)_(No_response_Bim Liam Denis Howard) Found Date: 24 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/24-eo-minutes.html People with action items:[End of scribe.perl diagnostic output]