Tutorials, Images and Forms

<shawn> survey results https://www.w3.org/2002/09/wbs/35532/EOWG20150213/results

Shawn: Thanks for all 16 who took the survey. Eric reviewed them and made some changes based on your comments.

Eric: Yes, thanks all for your responses, very helpful. You identified quite a few typos and things, thanks very much, very helpful. Other changes suggested were the references to screen magnification. Wayne commented that screen magnification was not the best way to describe. We changed the reference to low vision on many pages.

Eric: on images cover page, we removed sentence referring to alternative text, since people found it unclear.

<yatil> Removed: [[Also, there is no need to repeat the information in the text alternative when the page containing the image already describes information provided by the image. For example, the text alternative can simply refer to the description of the type and look of a bird, if that information is already provided on the page.]]

<yatil> https://w3c.github.io/wai-tutorials/images/complex/

<yatil> https://w3c.github.io/wai-tutorials/images/complex/#description-containing-textual-information

Eric: One of more significant changes was on complex images. Page is now split to 2 examples. If you use ARIA there is no real semantics available so our table example was a poor one. We have better examples now more appropriate for ARIA describedby

<yatil> https://github.com/w3c/wai-tutorials/commit/5c35baac05e0702b836a4c2c1540f05c1990c367

Eric: We updated the reference to longdesc. Otherwise there were minor things, word polishing nothing more that is added to the meaning of the page. We needed a better description of when to use ARIA alerts to notify user and so added a description that I hope makes the example much more clear.

Shawn: Any questions or comments on those changes? Would you like us to provide a list of the changes made?

Sharron: Might be useful to have a list for those not here today.

Shawn: Eric, was the tab focus indication addressed?

Eric: Yes

Shawn: And Reinaldo's comment on CSS?

Reinaldo: I reviewed the decision tree and my question was why not suggest the use of the image replacement techniques?

Eric: That technique is less used now that there are better support for fonts, so we did not address that technique since it is more about fonts than images.

Shawn: Do we need to mention it at all even if we do not provide and example or recommend that technique?
... do we need to acknowledge or mention it somewhere in the Tips?

Eric: Maybe but I do not really understand the use case.
... what were you looking for Reinaldo?

Renaldo: Considering the recommendation of background images rahter than empty alt attributes.

Eric: Oh yes, we do mention that a few times ...within decorative images, before first example.

<yatil> https://w3c.github.io/wai-tutorials/images/decorative/

Shawn: Can you make sure it is resolved to address Reinaldo's concerns - keep as an open issue?

Eric: Yes sure

Shawn: OK then once that is addressed, we'll post a list of changes and hopefully get it approved in tiem for CSUN

<yatil> Change: [[Sometimes, for example, when using AJAX techniques, the browser is not loading a new page but shows changes, such as form errors, dynamically on the page. To inform the user in such a case, the list of errors should be inserted into a prominent container on the top. In addition to the advice above, this container should have the `role` attribute set to `alert` to make assistive technology users aware of this change.]]

Howard: When reading this I felt that the recommendation was to always put the messages at the top of the form but my understanding was that a better practice is to place it near the input.

<yatil> [[Provide feedback to users about the results of their form submission, whether successful or not. This includes in-line feedback at or near the form controls, and overall feedback that is typically provided after form submission.]]

Eric: Actually there are some cases in which both are needed, especially when the forms are long and it may not be practical to only have the notice near the input but must call attention at the top as well. We will make that clearer.

Shawn: OK, moving on

Tables Tutorial, types of tables

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWG16Feb2015/results#xtablesty

<shawn> Tables Concept page: http://w3c.github.io/wai-tutorials/tables/

Shawn: We have comments from Melody, Eric and Kevin, their ideas for short names. Based on those, let's think about how to call the types of tables.

AnnaBelle: Has there been a problem with people understanding them as they are now?

Shawn: Yes they are not clear.

AnnaBelle: For whom is it not clear?

Shawn: Several of us, but with these ideas, we are getting closer to a clear naming convention it seems to me

<shawn> 1. Single header

<shawn> 2. Two-dimensional

<shawn> 3. Spanning header

<shawn> 4. Multi-header, multi-level

<shawn> kevinL

<shawn> Single header

<shawn> Row and column header

<shawn> Multiple row or column spanning header (too long :()

<shawn> Multiple header cells

<shawn> eric's idea:

<shawn> * Simple (or Basic?) Tables

<shawn> * Common Tables(?)

<shawn> * Scope

<shawn> * Headers & IDs

Sharron:Sharron: Kevin's comments from the survey indicated that it may not really matter how the tables are named. He said "does it really matter? What is the primary access point likely to be? If it is the concepts page then the terms are described. If it is accessed via deep hits then the context of the page should provide enough information - perhaps with a minor modification of including the sample icon. I know this is contrary to what I commented on elsewhere."
Given Kevin's comment why do we think they need to be renamed?

Shawn: Those comments were made in isolation without considering the broader content.

Howard: I tend to agree with Sharron. Trying to find a more descriptive title may cause greater confusion. I am not sure you can do this with a short name. There is a risk of it being more confusing. Once you get started in exploration, it becomes clear what is being defined.

Shawn: If you went through and read it all, and I cam back later and I asked you what is a simple table, a regular table, and irregular, etc would you be able to tell me?

Howard: Maybe but I am not sure it is improtant that I remember exactly which is which so much as that I know how to find what I need.

AnnaBelle: I agree with Sharron and the direction that Howard is going in. It is OK to define a term and use it consistently. To my mind it is named according to how I will use this as a developer.

<metzessive> +1 to scanning the icons!

AnnaBelle: I will be scanning the icons and look for the match of what I am looking for, not caring so much about the name.

Shawn: Since we have some with strong feelings that different names are needed, can we look at the suggestions?

AnnaBelle: And without user testing, we do not know if the suggestions are useful .

Shawn: We don't have plans (or resources) for usability testing

AnnaBelle: I question that decision, seems very important.

Sharron: Annabelle, let's you and I talk about that offline

Shawn: We have usability tests planned for WCAG-EM tool, QuickRef, and Dynamic Planning Guide

<Howard> Sharron, AnnaBelle, I'm willing to help with the usability testing

Melodye:The reason why I suggested the names I did was simply to call the tables for what it is, which is - a table with a single header, spanning header or multiple headers/multiple levels

<melodyma> and I believe the technical term for a "simple table" is "two-dimensional"

<melodyma> But I agree that as a Dev, I'm likely just going to go to the first page and look at the reference diagram before navigating to the section I'm looking for

<shawn> Single header

<shawn> Row and column header

<shawn> Spanning header

<shawn> Multi-level header

Sharron: I have a suspicion that these names will be more confusing but I do not feel strongly

Shawn: What do others think?

<shawn> latest draft:

<shawn> 1 Simple Tables

<shawn> 2 Regular Tables

<shawn> 3 Irregular Tables

<shawn> 4 Multi-level Tables

<Howard> Of the suggested changes, I like Melody's the best

<shawn> possibility (tweaked from Melody's):

<shawn> Single header

<shawn> Row and column header

<shawn> Spanning header

<shawn> Mulit-level header

<AnnaBelle> I find those confusing. Prefer current.

Sharron: +1 to AnnaBelle

<metzessive> +1 AnnaBelle.

Eric: I am not really sure. I agree with AB, these are a bit confusing. I am not sure, sorry.
... I think that if someone comes to the page trying to learn about tables, I would be confused by the focus on headers. May not be thinking in those terms.

<shawn> Single header table

<shawn> Row and column header table

<shawn> Spanning header table

<shawn> Mulit-level header table

<melodyma> I'm happy with whatever the group thinks makes the most sense.

Sharron: It would introduce confusion by assuming that the person looking for information knows something about table headers.

<Reinaldo> I agree with Eric. Simple descriptions sounds better.

Shawn: [taking off chair hat] Having these categories that do not mean anything. That is the difficulty for me. Since Shadi, too had a difficulty, we should get his input.
... if we continue to use the titles that have no meaning, each has a few sentences that explain what they are, including those in bold might help.

<shawn> [arbitrary - that was the word I was looking for all this time]

Sharron: Doesn't the meaning become clear with the definititon?

Shawn: I see the names Simple, Regular, etc...I have no idea what that means. If I look at the definition, there are some explanatory phrases. If those were bolded it would help I think. Any objection to trying that?

Sharron: No not at all

Eric: No objection

<yatil> https://www.w3.org/2002/09/wbs/35532/tablesapproval/results

Shawn: We asked for the Tables Tutorial by Wednesday, some have done so, if others can do that soon, we have a good shot at getting it done by CSUN. Any other comments on the Tutorials?

<Howard> tutorials look great

Paul: Since this is not a specificiation document, does it make sense to put those more precise descriptions next to the icons?

WCAG-EM Report Tool

Shawn: We are asking for this to be completed by Tuesday. Several have already done the review, please try to complete as soon as you can.
... with the WCAG-EM Report Tool we are continuing to work on it even though it is highly polished, we are still making improvement. Wilco is proud of his work and is still willing to dedicate time, which is great. Assuming that we want to communicate that it is ready for use but that we have a list of future improvements. Should we publish a list of specific questions when we publish the doc that helps collect usability data?
... do we want to have a static WAI page that lists updates, a blog post, a wiki, W3C surveys or how to collect data? Any of your ideas are welcome for how to provide info on updates and collect feedback?

Sharron: these are all good ideas, the question is how to implement and maintain?

<yatil> https://github.com/w3c/wcag-em-report-tool/issues

Shawn: The other issue is that we have a fairly long list of planned updates, on the GitHub issues list which is three pages of suggestions that are not well organized. Do we need to (and then how to) refine the use of GitHub to be more helpful?

<yatil> Stuff for Milestone Version 1.0: https://github.com/w3c/wcag-em-report-tool/milestones/Release%20version%201.0

Paul: Some projects I work on have the idea of an icebox, those things that are planned but not immediate as well as the items that we ARE currently working on. This current GitHUb will not be helpful for general public.

Shawn: What would be more helpful for the public?

Paul: Not a static page, since those tend to get out of date.

Sharron: What would you think of a blog with comments enabled?

Paul: Pretty messy, wild west. We have had this discussion internally. We have good internal tools but the problem is how to get feedback from users who may not be developers at all.

<yatil> https://github.com/w3c/wcag-em-report-tool/milestones

<paulschantz> there is some effort involved in presenting this info

Eric: It is up to the maintainer of the repository to organize the comments as they come in. There is a possibility to better curate the list of submitted issues.

AnnaBelle: Are you saying that the GitHub collection of issues could be better if it was managed more closely?

Eric: Yes, if there are rules for submissions and the comments are curated.

<paulschantz> who would do that?

Paul: I would support a blog if it was very specific as to topic and management

Shawn: In the past we've done blogs and gotten very few comments. Do you think there would be more response to a blog than to send an email?

<paulschantz> I only comment on blogs if there's no (or very little) friction to doing so.

AnnaBelle: If your goal is quantity, email is the way to go.

<paulschantz> solicit feedback from the tool itself

<AnnaBelle> +1 to jonathan

Jon: I think that blogs can be very useful but not ifyou only do them occasionally, people may not know it is there. It must be used more regularly. There are some blogs I visit just for the comments.
... when they are available from the community. Would need to remove barriers and make it easy while maintaining some control.
... Maybe we need to start allowing any EO participant to author a blog

<AnnaBelle> Maybe we could use analytics on just this one tool? Not sure it's the best for analytics, but another option.

Shawn: In the Tutorials we have a nice big notification that tells people how to comment and provide feedback. We do not have that on the WCAG-EM Report Tool and perhaps we should do that.

<paulschantz> +1

Shawn: do we all agree that on the page itself we pump up the visibility, clarity of the call for feedback? Any concerns with that?

<yatil> +1

<kevin> +1 :)

Sharron: agree

<paulschantz> +1

<Reinaldo> +1

<AnnaBelle> +1

<metzessive> +1

<Howard> +1

RESOLUTION: For WCAG-EM Report Tool make the request for feedback much stronger and more visible

Shawn: And AnnaBelle about the analytics, we are planning to do very specific analytics on each page...how far do people get? do they stop on a certain page? what is rate of abandonment?

AnnaBelle: For something specific like this, it will be quite useful IMO

Shawn: And to follow up on the idea of making the blog public, we do not have the ability to manage difficult discussions. We do not have the resources to manage a sufficiently vetted response from staff.

Jon: The way that you could easily fix that is to have a disclaimer, that the blog posts do not reflect WAI
... if you make clear that it is an author POV you would not have to worry about formal response from WAI
... you are seeking informal conversations and opinions

AnnaBelle: I had a memeory of when we were working on that Tool that there is a privacy statement in there that may need to be reviewed before implementing the analytics.

WCAG Quick Ref Mock-Up

<shawn> https://w3c.github.io/wai-wcag-quickref/

Shawn: Melody has commented in the survey
... again this is still a very early mockup, thanks Eric for giving us lots of opportunity to comment

Eric: I have mostly been playing with the ideas provided earlier. The top navigation provides access to a Glossary and such. We are thinking of adding a print option. Note that currently the icons are missing, I do not know why. Missing Print and Search icons
... I have included a Filter Preset that I hope will help people access content more efficiently.
... at the Top there is a three column Title of SC, Techniques and Related Resources. There is tabbed navigation to get to SCs, ACs and more. Allowing you to step through the categories of Techniques. Will have the options to Show All techniques as well.

Shawn: Early prototype this is your opportunity to provide initial feedback, what are first impression, questions, etc.

<shawn> s/Whenever "limited resources" are brought up my cynical hat goes on./ /

Paul: Love it but still think it needs ability to collapse some of the content, like the main sections
... accordians on some of the main sections

Paul: I would prefer to see the detail collapsed intially

<metzessive> +1 collapsed initially

Howard: What about some type of horizontal menu on the top, to give people a sense of what lies below without having to scroll

Shawn: Having all SCs?

Howard: No but at the level of Guidelines, it would be useful to know how it is organized

<kevin> +1 to more navigation options

Sharron: +1

<paulschantz> +1 to Howard's concept, not sure on implementation

Eric: It is hard to get an overview of the page and not get lost.

Shawn: Any other general comments?

Kevin: I am not sure about visibility of the filters and the clarity of their use? I think they are so important and not sure that importance is communicated. may be hiding a bit.

Eric: I have added the Filters to have an impression of the apperance. There may be more filters added, but wondering if people will really use them?

Shawn: What were you thinking with the provision of Filter presets. For example I have trouble envisioning what will happen when I choose Authors for example since W3C defines authors as essentially everyone.

Eric: I know that at the moment they are broad. For me I was thinking of content authors and it would include some general guidance on images and text related items but not so much on sign language and media

Shawn: Are they redundant to the responsibilities filter?
... my first reaction is that the Filter presets could add more complexity than benefit.
... did you deliberately turn off the ability to avoid the Techniques altogether

Eric: You would have the opportunity to uncheck them all and the preset would be applied
... I wonder if it is clear what is the use of the Search function?

Shawn: What if someone put in something that was not anticipated?

Eric: At this time there would be no search results, to do that we would have to have a full text search function.

<paulschantz> it's not strictly a search function

Shawn: My inital feeling is that a Search may not be really useful if you can only search for the filters that are already here. A full text search would be more useful but challenging in terms of how it is presented in the Results. For example a search for CAPTCHA or ASCIIart

<paulschantz> it's a list filter

Howard: I like the search function and think it adds usefulness for those seeking specific information. having a full search function will be helpful.

Eric: Can we have anotehr look at the Filters? It is a very open question. I would be interested to know what presets would be most useful? what combination of things can you imagine you might want?

Shawn: When we talked about Roles, it was challenging. You are talking here about Responsibilities which seems a good direction, do we want to consider Tasks instead? What am I doing now?

Shawn: the other thing was that it feels like the Components - the specifics of what you are working on seems useful, maybe even more so that Devices.
... any more on this?

Shawn: please check in on the surveys complete them as soon as you can. Happy Friday good weekend

trackbot, end meeting