Education and Outreach Working Group Teleconference -- 20 Dec 2013

<trackbot> Date: 20 December 2013

trackbot, start meeting

<trackbot> Meeting: Education and Outreach Working Group Teleconference

<trackbot> Date: 20 December 2013

<scribe> Scribe: Sharron

<dboudreau> morning all!

Introductions

Shawn: Let's all take a minute to introduce to new WAI staff member Eric

All: Introductions

Eric: From Germany, coming to EO from the development side of the web, active in accessiiblity for 7 or 8 years. See http://lists.w3.org/Archives/Public/w3c-wai-eo/2013OctDec/0053.html End of first week, happy to be here.

<dboudreau> happy to have you join us, Yatil :)

Shawn: Eric will work on WAI-ACT, the tutorials that were started by Bim. His background includes work on the BAD

Easy Checks

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks

Shawn: We must publish to day if we want it ot be part of the W3C announcements. Let's look at open issues from the top

<shawn> If the image has complex information — such as charts or graphs — the image should have a short alt text identifying the image, and then the detailed description of the information should be provided elsewhere (for example, in a data table).

<Sylvie> ZAKIM? MUTE ME

Bim: I am happy with "what the image is about" without going into unecessary detail.

<dboudreau> +! to what he image is about

Shawn: And remember when the images tutorial is available we will pont to it

<shawn> If the image has complex information — such as charts or graphs — the image should have a short alt text identifying what the image is about, and then the detailed description of the information should be provided elsewhere (for example, in a data table).

Helle: I have some concerns. It may be hard to translate. In Danish it would translate to be what it looks like. And we tell people to think aobut fundtion rather than appearance.

<shawn> denis first suggestion "the image should have a short alt text describing the nature or purpose of the image, and then the detailed..."

Denis: We can't talk aobut functionality with complex images. It may be as simple as to provide the data in a table. What the image is about then summarizes the visual presentaion of the data and points to a table of data.

Helle: Yes I understand better now, it should be OK
... OK if I understand the context as being about complex images, it is acceptable.

Sharron: So "what the image is about" is OK with you?

Helle: Yes in this context it is.

Sylvie: Well, I understand this concpet and seems clear enough to me. Another possibility would be "the topic of the image"
... "what informatio is conveyed"

Sharron: A summary of the image content

<hbj> +q

Sharron: although I like "what the image is about" it seems concise and tidy

<Sylvie> what about : "summarising the information conveyed by the image".

<Sylvie> or information contained in the image.

Helle: To some of us it goes back to historical education of not expecting visual description but meaning or purpose of image
... would it not be more accurate to use this only with complex images (graph and charts specifically)?

Sharron: yes that is the purpose

<Bim> +1

Shawn: I propose that we use the current wording and leave it on the list for future consideration.

Sharron: +1

<hbj> +1

<IanPouncey> +1

<dboudreau> +1 to moving forward

<yatil> +1

Shawn: Next point was at the end of this discussion, to add for example in a data table or longdesc
... I propose that we do not go there since that is a bugaboo, a complex issue that goes beyond Easy Checks

Howard: Sure, that's fine

Shawn: Next point was too move the expand / collapse

Denis: ONly on this one?

Shawn: Yes it would be somewhat inocnsistent but ...Howard?

Howard: Here, the "Tips" seem very crucial information aobut what actually IS needed for appropriate alt text.
... I don't see how a newbie would fully understand the proptocols without the "Tips" inofrmation

Denis: Add you could easily miss that section when it is collapsed

Bim: The problem is with the term "Tips" on its own. Perhaps Tips and Examples

Shawn: If we moved it, it will add just two paragraphs. And the content is probably good for all to see.

Denis: We have some h3 that are not collapsible. Why wouldn't we put the collapse on the Alt text Checks

Shawn: Proposal is to move Expand-Collapse one level down and put the second paragraph in the collapsed section

<shawn> +1

<dboudreau> +1

<Bim> +1

<Howard> +1

<yatil> +1

Sharron: +1

<IanPouncey> +1

<hbj> +1

Ian: I have some additional comments about the alt text section. They are fairly straight forward
... I like the way that alt is called out as an attribute and not a tag - well done!

<IanPouncey> alt is an attribute of the image element, and other elements

Ian: should be alt is attribute of image element, not image tag

<IanPouncey> "alt is an attribute of the image tag, and other tags" -> "alt is an attribute of the image element, and other elements"

<shawn> EDIT ^^^

Ian: Related to no alt text, even a decorative imge should have alt text if it is meant to be downloaded and used again

<shawn> subtopic: Heading

Shawn: That is a very particular instance and since we are not trying to be defintitve are you OK with something at that level of complexity be omitted until the tutorials

Ian: There is currently no mention of HTML5 heading structures

Shawn: Anything specific for the NEXT draft can go into the wiki and can llook for next round of updates and revisions

<shawn> subtopic: text resize

Ian: On text resize, why in the suggested how to check is to increase using the plus four times? When I tried it in the FF browser, it did not get to 200%

Shawn: The keyboard controls move it either too much or not enough, so we made this call

<shawn> subtopic: keyboard

Ian: For keyboard access, in OSX tabbing through nonform elements is not enabled by default

<IanPouncey> Best guide to enabling keyboard access: http://www.456bereastreet.com/archive/200906/enabling_keyboard_navigation_in_mac_os_x_web_browsers/

Ian: it can be enabled using this guide. Can we link to that or summarize the method within the Easy Checks?

<yatil> That’s really ridiculous on OS X.

Shawn: Do you need to do this for all OSX browsers?

Ian: Yes, otherwise you can tab only to form lelements, not to links.

Sharron: Could we not just link to that Guide instead of trying to relpicate the instructions?

Shawn: WAI is very careful about linking out

Ian: Not sure if there is an equivalent on any of the W3C sites, but I can look.

<yatil> It is a bit outdated, the System preferences changed a bit in the meantime.

<dboudreau> the information for safari is still 100% relevant today

Eric: We may need to consider how to address this because some may be outdated

Shawn: It is important to address so I think we make a note that on OS testers must enable full keyboard access
... but we do not link to anything for this draft

<dboudreau> works for me

Sharron: Yes that seems a good temporary solution

Shawn: Can you suggest wording?

<shawn> EDIT: to "In a browser that supports keyboard navigation with the Tab key (for example, Firefox, IE, Chrome, and Safari; not Opera):" need to enable in some Mac browsers

Ian: Use the broadest language, that edit looks good to me
... Finally we talk about being able to access media player controls but fail to mention the inherant barriers in Flash woithout Javascripting
... you will not be able to make Flash keyboard accessible in every browser
... there are WCAG2 techniques that we could link to?

Shawn: We are trying not to point to specifc details like that. Rather to the SC related to it

<shawn> proposal: "Tab to all: Check that you can tab to all the elements, including links, form fields, buttons, and media player controls." add (A common problem is that you cannot tab to media player controls.)

<IanPouncey> (Here is the technique: http://www.w3.org/TR/WCAG20-TECHS/FLASH17.html)

Shawn: is this an unecessary detail, important to add, what?

Denis: It adds value to mention itl, let people know what to look out for

Sharron: +1 to Denis

Ian: The media section references this, so this is the place to put the alert for new testers.
... it would also apply to games, etc

Howard: I agree with Denis and Sharron it is worth mentioning

<dboudreau> +1

<Howard> +1

<hbj> +1

<Jan> +1

<IanPouncey> +1

<yatil> +1

<dboudreau> actually, +1 if t doesn'T set us back with publishing today

Bim: Only thinking that it is unusual in EasyChecks for a common problem to be called out like that.

<shawn> EDIT: "Tab to all: Check that you can tab to all the elements, including links, form fields, buttons, and media player controls." add "(A common problem is that you cannot tab to media player controls.)"

Shawn: For this section we call out common problems twice
... Anything else Ian?

Ian: No I am done causing trouble

Sylvie: INstead of a common problem is, can we say a known issue and it is not always possible to tab through media player controls with every browser or AT

Shawn: In the next, we have the verbiage about keyboard trap
... mouse dependency, etc so we use the term common problem elsewhere

Sylvie: Oh OK I thought you were looking for another word there

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks#Forms

subtopic: forms

Shawn: Two things:
... a note in the Forms section

<shawn> "Note: This section is more complex. If it's too complicated, consider skipping it for now and doing the next checks for multimedia and structure."

Shawn: Everyone seemd OK with the wording

<Jan> +1 than the others

<Sylvie> yes

<Jan> +1 on moving forms to the end

Shawn: Sylvie suggested to add "more complex than the others"

<shawn> EDIT: ""Note: This section is more complex. If it's too complicated, consider skipping it for now and doing the next checks for multimedia and structure."" -> ""Note: This section is more complex than the others. If it's too complicated, consider skipping it for now and doing the next checks for multimedia and structure."

<dboudreau> +1 to "than the others"

Shawn: What about the order of the EasyChecks? Ian? Eric? some new perspectives?

<yatil> +1 for reordering later

<Howard> +1 for reordering later

<hbj> +1

<Howard> isn't this our Xmas present to the world?

<Bim> Publish!

<yatil> :-D

+1 for reordering later

Shawn: To be clear that we are only changing from Editor's Draft to WG Draft and making an announcement

<dboudreau> +1 to reordering later too

Denis: The open issue of keyboard access to captions in YouTube is still not possible

Shawn: Seems all are comfortable with Basic Structure (View)
... so on to the next, we are looking in BAD Eric maybe you can help
... we say to proactice checking structure with BAD

<shawn> http://www.w3.org/WAI/eval/preliminary#plainBAD

<shawn> ^^ add action for Eric :)

<shawn> http://www.w3.org/WAI/eval/preliminary#next

Denis: Tables are much more difficult to test when you are not technical

Shawn: Yes that is why we say "Hey this not a definitive check and here are some of the things that are NOT covered here"

Ian: What wouold cover under redundant color coding

Shawn: required fields indicated only by color..that is an old WCAG1 term, so maybe we should update the wording

Ian: Checks for links could be as simple as making sure your link has content

<yatil> Reliance on color coding?

Shawn: We had one for a while and it got to be too many false positives and complications and qualifications that made us delete it from an EasyCheck

<shawn> EDIT: "Redundant color coding" -> "Reliance on color coding"

<Howard> +1 for move to "reliance"

Shawn: Helle had suggested definition lists to be considered for next draft

Helle: Came up when we found that when people pay attention only to WCAG2 AA they miss some AAA items that are actually easy to implement

<Bim> +1

<yatil> +1

<IanPouncey> publish

<Jan> +1

<Howard> +1

<dboudreau> +1 to publishing this next draft

<shawn> publish & announce working group draft today?

Shawn: Question is to publish today?

<hbj> +1

<Sylvie> +1

<shadi> +1 to publish as a draft

Sharron: +1

<Jan> +1 publishing and announcing

Shawn: Thanks so much for your contributions. After the call, I will put the changes in the wiki, make the updates to the Draft, publish as Working Group Draft....and announce!!
... we are redoing all of the illustrations with the guidance we have gotten from the general specification development

Evaluation Tools DataBase rejig

<shawn> http://www.w3.org/WAI/EO/wiki/Evaluation_tools

Bim: After the input and discussion about users we had a few weeks ago, I rewrote the stories and what I would really like are your views on what might be missing
... look for redundancies, are any of the Use Cases exact duplicates? any other suggestions are welcome but especially have we gotten our most likely user stories captured?

<shawn> old db http://www.w3.org/WAI/ER/tools/Overview.html

Shawn: What this is for is when the Evaluation Tools DB is updated, we want to provide context for who will use it
... how will they use it and since this is just internal to help us as we develop the DB just make sure we have the right scenarios to guide the development of the tools database to amke sure that we are meeting all needs
... Ian thanks for coming and before you go, we want to meet for EO at CSUN so keep that in mind as you schedule

Howard: I have a question - this is an internal list? we won't publish the database?

Shawn: No the database itself will be public but the user stories that we are relying on to guide the development of the DB is internal only

Howard: Yes I can see that this could be a great tool when updated.

Shawn: So looking at this list, is it complete?

<Zakim> shawn, you wanted to ask [after other specific comments] if want/need to prioritize

Shawn: Question I had was what is the grouping or prioritization of this many users? Should we group them? or are you happy with there being 12 + equal needs groups?

Bim: Yes it would be useful to have a prioritized list

Shadi: Yes seems like the next step is prioritization. But if we tke a bit more time, we may come up with more examples of users.
... make sure all of those scenarios are covered. Some will overlap in terms of functionality
... we will find some of that as well but I just want to make sure that before we begin to prioritize that we have all bases covered
... now the you have nothing to do over holiday break, give it some thought

Denis: There are monitoring tools but what about developers working alone vs QA people working alone. if we started by categorizing in terms of roles we could reassign the different elements we have within those categories

<shawn> previous version based on roles http://www.w3.org/WAI/EO/wiki/index.php?title=Evaluation_tools&oldid=7347

<dboudreau> @shawn oh, ok

Shawn: Bim's different approach based on roles began to be hair-splitting

Bim: Regardless of the role they are in, we focused instead on what they are trying to do

Shadi: there is a role in the scenario and there is a tool description or mention as well

<hbj> +q

Shadi: seems like a scenario might be a better approach than either focussing on the specific tool or the specific role.
... a focus instead on the task seemed to us the most useful approach

Bim: We tried to be a bit specific to give the description some life but the auto tools check is something that could be used by any number of the individuals in the scenarios list

Helle: Just wondering if this would also cover end users, if I am experincing barriers and want to validate that there is a conformance issue as well

Bim: Is this something that people might spend time on in the next couple of weeks? And adding comments?

Sharron: I can

Shawn: Reviews coming up, please look at ATAG, WCAG-EM review. Have great holidays and will see you in 2014.

<yatil> Happy Holidays! :-D

<Howard> bye

<Sylvie> happy holidays bye

- DRAFT -

Education and Outreach Working Group Teleconference

20 Dec 2013

Attendees

Contents

Introductions

Easy Checks

Evaluation Tools DataBase rejig

Summary of Action Items

Scribe.perl diagnostic output