WCAG Comment

<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2014JanMar/0034.html

Shawn: The link is to our comment and the reply from the WCAG-WG..Take a moment to review
... I saw some comments like typos, but first let's take a pass at it from a high level, the comment approach rather than fine tuning, wordsmithing

Andrew: I see a change in the sense of what we meant. Their reponse is similar but not quite the same. It doesn't say quite the same thing.

Shawn: It's wimpier.

Sharron: The way they they phrase it seems more wide open and easier to misinterpret.

Andrew: I can see why they changed the second sentence to make it more specific to WCAG2

<Jan> Here is a recorded webinar about the DIAGRAM Center's Accessible Images Sample Book: http://www.diagramcenter.org/webinars.html

Shawn: One of the examples is the fact that Flash is still not accessible on Mac.

AnnaBelle: IOS, not Mac

Shawn: In our wording , the first sentence covers a situation like that. Their rewrite does not.
... other comments?

<Jan> Here is a link to how to downloade the accessible images sample book from the DIAGRAM Center: http://diagramcenter.org/standards-and-practices/accessible-image-sample-book.html

<Andrew> give iOS example as to why we prefer our wording

Shawn: do we see wording in their sentences that we might begin with agreement, to guess what they were trying to change in ours and accept that change?

Sharron: One thing is the more specific reference to WCAG2

Howard: Maybe their goal was to shorten the phrasing.

<Andrew> suggest: Developers need to be aware of the limitations of specific technologies and provide content in ways that meets WCAG 2.0 success criteria and conformance requirements.

Shawn: Let's look at the second sentence. We say "accessible to all potential users," they reference WCAG2

Andrew: Maybe something like this (IRC)

<Andrew> Developers need to be aware of the limitations of specific technologies and provide content in ways that meets WCAG 2.0 success criteria and its conformance requirements.

Andrew: So they may accept that instead of our slightly looser "accessible to all potential users"

Shawn: Is that now strong enough?
... it is probably more technically correct but still has the potential to leave out something like the Flash example.
... I want to make sure that people who don't have as much accessibility experience could easily miss it.

Andrew: I agree that not everyone is going to understand it, but moves it more to the technical expression they seem to be seeking.

<shawn> Developers need to be aware of the limitations of specific technologies and provide content in ways that meet WCAG 2.0 success criteria and conformance requirements and is accessible to all potential users.

<shawn> Developers need to be aware of the limitations of specific technologies and provide content in ways that meet WCAG 2.0 success criteria and conformance requirements so that it is accessible to all potential users.

Andrew: By having the technical aspects lead to the "all potential users" it becomes stronger

Sharron: I agree

Shawn: Did we get the sentence tense corrected, Jan?

<shawn> ours: Publication of techniques for a specific technology does not imply that the technology can be used in all cases to create accessible content that meets WCAG 2.0.

Jan: It should be ways that meet, not meets

<shawn> they say: Publication of techniques for a specific technology does not imply that all uses of that technology will meet WCAG 2.0.

Andrew: It may be in some situations

<Andrew> in some 'situations' rather than 'cases'

Sharron: accessibility support, can we bring that it to clarify?

Shawn: That is part of it, but not all

Jan: Can you expand on that?

Shawn: Just because there are techniques for specific technologies, that does not guarantee that the technology will be accessible for all users.

Sharron: Yes that is really important.

Shawn: And we need to tie it back to WCAG2. Let's explore "situation" rather than "cases"

<shawn> Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create accessible content that meets WCAG 2.0.

<Andrew> +1

<yatil> +1

<Howard> +1

<Sharron> +1

<Bim> +1

<Jan> +1

<paulschantz> +1

Shawn: In the interests of time, I propose that we reply with the fact that we don't accept their rewrite and need to work together to find a mutually acceptable alternative.

<shawn> [no objections. resolution]

Shawn: We had talked about the issue with aria-lable

Sharron: For me, a strong reason to ressit the full embrace of aria-label as an alt attribute substitute is the fact that aria attributes are not displayed when images are disabled. Rich Schwerdtfeger and I talked for a long time about this issue. He feels pretty strongly that aria-lable is an adequate substitute, especially given the history of the alt attribute as a bridge. He sees aria as the long term solution and his position is that the lack of display is a User Agent issue, not a WCAG issue.

<Jan> I have to log off of IRC to head over to Usability testing. I will be on the phone until about 8:45 and then will have to log off of the phone too.

<shawn> the comment that we submitted: http://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0023.html (which starts with "NOTE: Below is a rough summary of EOWG participants' comments, which EOWG did not have time to polish and approve. Please see the direct perspectives archived at <https://www.w3.org/WAI/EO/wiki/WCAG_Comments_February_2014#alt_issue>")

Andrew: One of Rich's issues was that it was a user agent issue, is that related to the conversation we had earlier, that user agents don't do the right thing? it is dangerous ground in my opinion.

Shawn: I think in terms of our comment, this does not change what we suggested.
... do we feel that this changes anything about EO's position?

Jan: I understand that perspective, but since one of EOs repsonsibilities is to bridge between reality and theory, we need to be very careful about what we propose.

<Andrew> +1 to Jan

<paulschantz> +1

AnnaBelle: It is important to have developer mentors who point out those aspects, however and I appreciate Rich's persepctive.

WCAG-EM Review

<shawn> https://www.w3.org/WAI/EO/wiki/WCAG-EM_review

Sharron: The dog ate my homework...I was editing away in the wiki and we lost connectivity at my office at UT. I lost my edits before I figured out what was happening.

Shawn: Sylvie, will you be on the call next week?

Sylvie: No I will not be able to join next week.

Shawn: The deadline is the 28th for comments, can we ask for an extension, Shadi?

Shadi: We have the F2F coming up before CSUN and clearly we want to be ready, so a couple of days might be OK but let's try to get them in so we can prepare.
... some of the comments have been unclear and there is internal discussion that makes it more ambigous what is meant.

<shawn> https://www.w3.org/WAI/EO/wiki/Action_Items#WCAG-EM_Review_-_in_Feb

Shawn: So as you review, please suggest specific re-wording, etc. We really need everyone to respond to this. If you choose to abstain, you need to make that explicit as well.
... any questions?

Tutorials

<shawn> https://www.w3.org/WAI/EO/wiki/Tutorials#User_Interface_Design

<shawn> updated draft: http://www.w3.org/WAI/EO/Drafts/tutorials/images/

<shadi> +1 to permalinks

Eric: First of all, we put a bread crumb trail as requested next week. The navigation should now be a bit clearer. No numbers on internal pages of each tutorial. Now you see the headings a bit differently and links to the various examples that can be quickly found and used.

Paul: I like the changes a lot, amazing how much more understandable the content is now
... visually appealing, more understandable

Eric: Example heading text has changed

Andrew: I see a great deal of blank margins on either side, is there a reason for that?

Eric: It is more readable if the horizontal lines are shorter. Perhaps will use the space to link to other resources

<paulschantz> I prefer the large margins, much easier to read

Andrew: But when using half screen size, the line length still leaves a bunch of white space and the lines become just six words or so.

Paul:at what width does the nav break to 100% width?

Eric: I am trying to make it work so we still maintain left nav and top nav

<Andrew> responsive works well as window shrinks

AnnaBelle: So you will continue to fine tune the break points? Is it possible to put the menu or some of the menu on the bottom? Maybe leave a small menu at the top but replace the main menu to the bottom.

Andrew: Yes, expecially since as the All Tutorials menu is likely to grow and grow

Eric: Perhaps use something like a accordian

Shawn: This is still a draft, we can still make changes for a little while. Not much longer so hearing the comments, we are in agreement about the changes - overall line width etc

<Andrew> overall - very good

Shawn: Are we comfortable with the current approach in terms of the line length and breaking points?

Shadi: Can we separate the two questions?

<yatil> Line length is based on Advisory Technique C20: http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/C20

Andrew: Not sure if the line length can be managed differently.

Eric: We could let go of the right column when we go into small screen mode

Andrew: It will depend on the use of the right space.

Eric: It will probably be links to specific Techniques
... it is context specific so will not wrap underneath

Shawn: Eric can you please skim the wiki comments and see if there are things you would like to discuss?

Eric: Yes, I would appreciate more discussion of left nav? Does it make sense, does it need additional cues like numbers, icons, etc

Paul: The design is readable, only wondered if the menu items may need borders

Shawn: We decided previously that we wanted numbers to encourage people to move through the entire tutorial in a flow. We can always revisit, but that is why we chose that.

Howard: I am on the fence with numbers, and see how it could add to wayfinding, but could also add visual noise.

Andrew: I like the numbers to show how many parts there are, let people know they are in part 3 or 5 or such
... adding horizontal lines (borders) will add to visual complexity

AnnaBelle: I like it fine with or without borders. I find the numbering ever so slightly confusing between the two menus.

<Andrew> could the current menu be labeled a, b, c to differentiate from the all tutorials 1, 2,3 ?

<Zakim> shawn, you wanted to say link numbering on top but not all tutorials

Paul: I was going to say that borders will be distracting. The active item clearly stands out from the rest. I was not in favor of the numbers at first, but now can appreciate the way finding aspect.

Shawn: I agree with Andrew about the numbers. To Eric questions about whether we need something to the left of concepts and FAQ, not sure...

Andrew: No, we don't

<paulschantz> +1 to that

Shawn: Agree that additional borders would add complexity. Have trouble with numbering of All Tutorials
... possibly icons but probably not.

Paul: I agree with no numbers next to All Tutorials

Eric: Yes we can remove those numbers, but would not add icons.

Sharron: +1

Eric: Will go back and shape it a bit.

Shawn: Anything else you need input on?
... still some comments in wiki

Shadi: At the top of left nav, is the word "Content" needed there?

Paul: I suggested that as well, remove "content"

Shawn: +1

Sharron: +1

<Andrew> +1

<paulschantz> +1

Shadi: and in next section, can we just say "Concepts" without repeating "image"

Shawn: I think we need it

Shadi: So we will have image concepts, table concepts, Information Structure concepts, it will get a bit redundant

Andrew: Would Overview be a better word to use than Concepts, also to align with other uses?

Shadi: Eric convinced me that the word "concepts" is important in order to encourage people not to skip it

Shawn: For now I think it is good and needed for clarity. It may not be appropriate for every page and may not need to be a hard and fast rule, but for now I think it is needed.

Bim: Thanks for putting Previous and Next at the bottom, much appreciated.

<Andrew> +1 to Bim's suggestion re previous/next links

<shawn> +1 to paul's idea for Images to be highlighted all the time

<Andrew> +1 to Paul's suggestion too

<Howard> it adds wayfinding to have it always highlighted

Howard: I had another suggestion, would it help to have a bit more spacing between each bulleted paragraph?

<Andrew> +1 too; we've done that on other pages

Shawn: I would agree that wherever the bulleted list is more than just a line, we need more space between them.
... what about second list?

<Andrew> eg http://www.w3.org/WAI/users/inaccessible#prob

Howard: That one, I don't see as much need. It is more of a standard bulleted list, but more space needed on the ones that are mini-paragraphs.

Shawn: If anyone wants to bring anything else to Eric's attention, use the wiki. Eric is updating the Tutorials regularly. Draft for review and the updated version is listed. To help Eric know which version camments refer to, I changed the wiki sections so that that was more clear. Does that work?

Eric: Yes this looks fine

<yatil> Added spaces between paragraphs: https://github.com/w3c/wai-tutorials/commit/d44f9230cfb7caca8abe0f7de770f4e23e9391e4

Howard: Do you want these suggestions that we have made today put into the wiki?

Shawn: Or just link to the minutes

Howard: When you hover, is there a better way to present that. It is a little bit subtle, is there a way to provide better feedback.

Andrew: On tabbing, there is a faint border, that could be improved on tab.

Shawn: Maybe make the hover display equal to the tab focus display?

Eric: Can't see that as necessary.

Paul: +1

<Andrew> +1 to Eric

Shawn: ...and please add comments as they occur to you.

Easy Checks Illustrations

<shawn> https://www.w3.org/WAI/EO/wiki/Easy_Checks_-_Illustrations#Illustration_inventory

Shawn: Here is current inventory created by AnnaBelle

AnnaBelle: We are blowing through these - Andrew, Shawn, Vicki, and I are the team..we expect to have many done very soon.

Shawn: Next week, AnnaBelle?

AnnaBelle: We could shoot for it as a tentative deadline.

Shawn: Andrew, I used some of your captions, mostly workd for word, some with a slight difference, and another approach for some.

Andrew: I will review, and let me know when more are needed

Shawn: Vicki will do hers this weekend so will have more early next week.

Comment on WAI-ARIA overview page

Shawn: We published as proposed rec and will soon be published as rec so it needs polishing before the big announcement
... how does the overview page work for people new to WAI-ARIA? Make comments in wiki

Reminders

<Howard> What time is that call?

Shawn: ATAG call next week, Wednesday evening in US, Thursday morning for Andrew

<shawn> teleconference logistics <http://www.w3.org/WAI/EO/#logs>

Sharron: Posted an email to the list, please review and add comments to wiki

Shawn: Should we look at WCAG-EM comments now or wait for more comments on further review?

WCAG-EM comments

<shawn> https://www.w3.org/WAI/EO/wiki/WCAG-EM_review

Shawn: Sylvie brought up a topic that I have wondered about as well - document titles
... Linked document titles are visually clear, but not so clear to screen readers
... ideas for how to address?

Sylvie: When I read that, I did not realize and did not notice the capitals on the titles, etc. Maybe put the title in quotes?

Andrew: What is the default for screen readers reading quotation marks?

Bim: Depends on whether you have identified as beginner, intermediate, or advanced user.
... perhaps start out by saying "the document blah blah blah"

<Andrew> Bim: The document Involving Users in Web Accessibility Evaluation provides further guidance ...

Shawn: Good brainstorm, but would that add clutter?

<Andrew> Bim: or - The document "Involving Users in Web Accessibility Evaluation" provides further guidance ...

Sylvie: When the capitalized words end, that is an indication of the end of the title.

Shawn: If links were read in a different voice, that would work

Eric: I think that is a wide spread problem, I am not sure that we can address it here.

Shawn: Good point. Resolution on that is to petition screen readers to use another voice for links or otherwise indicate the end of a link/

Bim: The slight rephrasing so that it still reads well but still indicates the status of those words as a title

Andrew: I was also thinking of someone like Wayne who applies his own style sheet, the addition of quotes could be useful.

Shawn: Would that add clarity or clutter for different users?
... let's look at one as an example

<shawn> http://www.w3.org/WAI/intro/aria

Shawn: reads, adding quotes
... consider that we have Overview documents that essentially are resources that link to many other documents. Would the series of quotes cause too much visual clutter?

Andrew: No more than the change in color/underline does.

Shawn: I will take this question out of the WCAG-EM comments and elevate it to a question of whether it should be included on WAI style guides

Bim: It will make a significant improvement in understanding. I often have to go back and read word for word, analyzing which is the document title that seems to throw the meaning of the sentence off.

Sylvie: For me it is a bit different, but yes, I often go back and read it again to see what is the title?

Shawn: Will have more on EasyChecks later in the week, so please do the other stuff early on. Some will be on the call on Wednesday, everyone else, see you next week.