Easy Checks - Forms

Shawn: One of the fundamental issues is the question of how to address the ideal vs the absolute requirements for passing WCAG2 when it comes to forms. So we need to define what we are actually asking people to check for and what is a pass/fail state.

<shawn> http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html

Shawn: Bim since you have been researching this for the tutorial, what is your perspective on the question of what is acceptable for passing WCAG vs what is recommended?

Bim: It is a bit confusing, there are SC's for 3.3.1 where explicit labels (matching the attributes 'label for' and 'form id') appear to be the way to demonstrate conformance.
... but it is not clear if it is an absolute requirmeent for conformance. I always recommend explicit labels, however. That is because some screen readers don't support implicit labels, nor does most speech input software.

Sharron: Why would we hesitate to ask for explicit labels?

Shawn: It is not clear that it is actually required for forms to be explicitly marked up in order to pass WCAG2.

Shadi: I guess it is percieved as an issue for user agents. Perhaps there is some kind of wording to indicate that it is the best way to insure conformance and interoperability with common software

Shawn: We can check for explicit labels but we cannot really fail a form that has only implicit labels.

Shadi: Do we want to ask the WCAG-WG?

Shawn: Yes, we could. I did find a provision where it says if you cannot do a label, you may use a title. So I believe their answer will be that you do not need explicit labels to pass WCAG.
... is this question too hard?

Sharron: We must address it, in my opinion.

<Sylvie> OK for me.

Shawn: Do we want to suggest and check for explicit labels with the disclaimer that even without them it could still pass WCAG?

Paul: It may not necessarily be required in order to pass WCAG but it definitely helps usability, because of the ability to activate a button with the associated text.

<Andrew_away> SC 1.3.1 - technique h65 states that the title attribute can be used to identify form controls when the label element cannot be used (a few circumstances imho)

Shawn: Which makes the point that the click in the text works with either implicit labels or explicit - those with matching labels and ids

Bim: Is wrapping the input field inside the label the only way that is considered implicit?
... I have thought that, but I ask because some screen readers that will not read a label if the input is wrapped within it.

Shawn: Have you noticed in the test page, there is a series of test forms. It would be interesting to check.

Andrew: There are some situations where you may need to hide off screen, etc or use a title. Not many, in my opinion. I saw your examples, I would not recommend the wrapped version.

Shawn: Yes but how to distinguish between not recommending and not passing?

Shadi: One issue is the difference between labels vs titles and the other is the difference between explicit vs implicit.

Shawn: Yes, because it is an EasyCheck, we do not use the terms, except among our own discussion. Look at the examples.

Shadi: It needs to say within.
... well why not keep it this way but modify the order and make a best practice note.
... they could examine at the code level.

SHawn: And that is another issue. We do not want to say "look at the code" because it is too scary for some people.
... the challenge is that this one, whether we want to check for explicit label, it is hard to check unless you look at the code.

<Andrew> I'm also concerned about the illustration that has the radio button labels positioned unconventionally to the left of the radio button

Sharron: Jim Thatcher's tool checks for that.

http://jimthatcher.com/favelets/

Sharron: and you get easy to understand results
... Jim asked Steve to incorporate it into the WAT and he said he would try to get to it this week.

Shawn: That would be very useful.

<shawn> Note that these instructions help you check only if a label is marked up in a certain way with <label>; they do not check if form controls are labeled in other ways that may be accessible. Therefore, even if a form does not pass these checks, it might still be accessible.

Andrew: Reads the disclaimer...

Sharron: should say "might still conform to WCAG"

<paulschantz> I think that any tool we recommend using in EasyChecks should reliably report errors

<paulschantz> if we have to use disclaimers...might not be very confidence-inspiring

Andrew: Are we accepting that wrapping without id is acceptable or that simple positioning is acceptable? Neither of those is covered in an SC?
... labeled in other ways vs identified in other ways.

Paul: What do we think about the lack of confidence engendered by disclaimers?

Shawn: Good segue to next point that the next part, click in the text field EasyCheck may not reliable enough to include?
... we are checking for explicit with matching 'for' and 'id' therefore the presence of implicit - just the 'label' is not enough.
... and let's all be sure to thank Steve for wrapping Jim's favelet in the IE WAT.

<Andrew> ACTION: andrew to follow up with SteveF re incorporating JimT's forms favlet into IE WAT [recorded in http://www.w3.org/2013/06/14-eo-minutes.html#action01]

<trackbot> Created ACTION-298 - Follow up with SteveF re incorporating JimT's forms favlet into IE WAT [on Andrew Arch - due 2013-06-21].

Shawn: The next section is to check for labels in the FF toolbar.
... these test forms all have implicit labels and so the FF toolbar does not flag it.
... Then to try to use WAVE, I know that some people find it hard to process the icons, but we have used the WAVE for some others. Andrew can you check?

Andrew: It gives an alert for some.

Shawn: It does give false passes for some of these that should not pass.

Sharron: You can install the Jim Thatcher favelets in the FF toolbar.

Shawn: But would be good to remain with the toolbars we have already introduced.
... (checks other EasyChecks - wanted to ensure your could check with any browser.)
... so we could decide to point to the favelets OR ask them to check code.
... what is the reaction of the group to ask people to look at code? is it too scary or is it OK in this case because it is an option made availabel to some?

Howard:agree, as long as it's one of many options

Andrew: I think it is OK since we would say "if you are comfortable with mark-up" Not everyone who checks will be afrad of code, may just not know about accessibility.

Sharron: I agree

<paulschantz> I agree too

Shawn: It is at the bottom, there is an alternative, and it is in a collapsable part. May not be too scary.
... finally there is Checking Forms with BAD. Shadi, Suzette, comments on what's here, what we might want to say?

Shadi: If you try submitting, you should get errors. There are some reading order issues as well that can be referenced.

Shawn: It stops at the Quick Menu

Shadi: Yes that is a bug. Once you are inside the page content however, you can tab into and when you submit, the error message jsut changes the field to red.

Andrew: Yes there is a clear difference between Before and After in the error message.

Shawn: Who will do a first draft of the instructions for how to check labels if you are comfortable looking at mark-up

<shawn> To check labels if you're comfortable looking at the markup

Sharron: I will

Andrew: Send to me for a check.

Shawn: Let's look at the intro now that we have made these changes.

Andrew: We should remove "wrapped in label"

Shawn: Done

Howard: Agreed, that sounds like implicit label

<Howard> yes

Shawn: We will make these changes, send out for review and then push out to the live Draft page.

Howard: I wonder about the sentence "when marked up in a certain way" is that not too vague, should it not say "correctly"

Sharron: "recommended way"/

<Andrew> when form labels are marked up correctly

<Andrew> Also, when form labels are marked up correctly, then the label itself becomes clickable.

<Andrew> Also, when form labels are implemented correctly, then the label itself becomes clickable.

<shawn> Also, when form labels are markedup, then the label itself becomes clickable.

Shawn: Could say, "when form labels are marked up, they become clickable"

Howard: I like correctly, but will go with consensus

<Bim> +1 for correctly

Andrew: same

<Sylvie> I like adding correctly, when you say "marked up" it is not precise enough.

Sharron: They could make the inference that it is accessible if clickable, but it is unlikely as Howard said

Sharron: Suggestion, replace "Also, when form labels are marked up in a certain way, then the label itself becomes clickable." with "Also, when form inputs are labeled, then the label itself becomes clickable."

<Andrew> disagree - 'labeled' could well be interpreted as visual labels only required

Bim: I have not come across anything that is a better explanation. I tend to use coding rather than markup when it is feasible. I will sometimes use HTML code in brackets if I use the term markup.

<shadi> "in the markup code"?

Howard: sounds better to use coding

<shadi> "in the markup code of the web page"

Shawn: If we limit the scope of EasyChecks to HTML, maybe the phrasing becomes clearer.

Andrew: Most of the other checks are based on HTML

Shawn: Except the media
... but not a big deal.

<Howard> Not sure.

Shawn: Let's get AnnaBelle's perspective since she has worked on it quite a bit.

<Howard> I would vote for keeping "mark up"

Shadi: The examples themselves tend to limit it to the HTML focus. It may be self-evident but we can mention it.

Howard: I prefer markup because it is pretty well known as a term, even for those who don't know how to write HTML. I think it is a clearer term and more recognizable for more people. Coding is vague and markup describes it better.
... I am happy to go with a group decision but that is my own perspective.

Shawn: One possibility is to explain in the Background section about what we mean by markup in that section and point to it later on. It will declutter the rest of the sections where we mention markup.

+1 for that idea

<Howard> +1

<paulschantz> +1

<hbj> +1

<Andrew> +1

Bim: Mention looking at source?

Easy Checks - Linearize (or Plain Text View)

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#l

Shawn: What do we want to call this?

Sharron: I like plain text view

Andrew: But it is more than plain text, since it is linearized as well.

Shawn: What else could we call it?

Andrew: Sorry, no answer for that.

<Bim> +1 for plain text

Howard: I like "plain text view" as well to cut through jargon. And, by taking out the styling, we are seeing the default state so I do not think the title is confusing and perhaps we can mention the linearizing effect in the text.

<Suzette2> agree plain text much easier to comprehend than linearise

Shawn: Good point. More important to be clear and not confusing than that the title include every aspect of the test.
... Sylvie, can you comment on your wiki remarks?

Sylvie: I tried to reformulate so that "some people" is not used so many times

<Andrew> Sylvie suggested a redraft in the wiki at http://www.w3.org/WAI/EO/wiki/Easy_Checks#Comments_on_Linearize

Sylvie: When people don't know how to operate a screen reader or don't want to download one, this linearization could be a substitute.

Shawn: Are you saying that we should be explicit in suggesting that this process could be a good approximation of the screenreader experience?

Sylvie: Yes

Shawn: We do mention it in the intro, is it insufficient?

Sylvie: I was working from Draft 2

Shawn: Helle, have you looked at the current draft and Sylvie's comment?

<shawn> draft 3 http://www.w3.org/WAI/EO/Drafts/eval/checks#l

<shawn> sylvie comment http://www.w3.org/WAI/EO/wiki/Easy_Checks#Comments_on_Linearize

Helle: Not ready to comment yet.

<Bim> +1 for saying that this view will give a good approximation of a screen reader user's experience.

Shawn: This is one where we could talk through it and come up with a good way to phrase this.
... hi Wayne. Even though we do not suggest that people use a screen reader, I am not sure that is the right way to phrase this.

Wayne: But one of the biggest ways that linearization helps people understand what is the experience for screen reader users and such.

Shawn: Andrew you noted the fact that data tables must be excepted.
... we should have reference to the linearization of data tables is problematic.

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#l

<shawn> To check plain text view with any browser

<shawn> Most browsers provide the option to turn off images and disable CSS from the menus. For example:

<Andrew> linearising a page with the FF toolbar completely stuffs up data tables (tried with BAD)

<Sylvie> I have access to mac at home with safari, I can try to have a look.

Shawn: Any other comments on this section?

Easy Checks - Next Steps

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#next

<Andrew> ACTION: andrew to add a note to 'linearise' in Easy Checks about issues when data tables are linearised [recorded in http://www.w3.org/2013/06/14-eo-minutes.html#action02]

<trackbot> Created ACTION-299 - Add a note to 'linearise' in Easy Checks about issues when data tables are linearised [on Andrew Arch - due 2013-06-21].

Shawn: Just to point out that based on last week's discussion, I made some edits. If you have any additional thoughts please add to the wiki

Easy Checks - Illustrations

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

Shawn: Reminder to email that Annabelle wanted us to think aobut strategy as it applies to illustrations. She wrote about her concerns and invited comments
... who else wants to work with AnnaBelle on the strategy for illustrations?
... then Andrew will you and AnnaBelle make your arrangements off list to collaborate on this?

Wayne: I support the process of developing a strategy for the images. We have not been strategic in thinking aobut how to use the documents.

UAAG review comments

<Howard> Yes, will get that in by Monday

<paulschantz> Yup

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

Shawn: Thanks to Bim, Andrew, Wayne for comments and Howard and Paul for review time. If everyone will agree to get comments in by EOD MOnday, we can review and be sure of what we want to submit as EO.
... so even if you just have a bit of time, please try to review and comment.
... not the deadline is Friday so our meeting next week will be the last review we will have as a group. Hope for the meeting is to be able to work through email and wiki through the comments and only review if anyone has concerns.

Wayne: I will be able to work through the wiki now that I have worked out my bugs with it.

Shawn: For all - if the wiki is cumbersome, send comments by email.

<Andrew> I couldn't work out the mark-up problems in the wiki at the Illustrations Strategy section - will keep investigating

Shawn: next week we will look again at the Big Picture for Tutorials (or whatever we call them) and invite review in the meantime. Shadi, Bim, any direction?

Bim: We have a slight change of approach on images and overall I would like to know if people understand what to do to get through the pages? Is it clear that each tutorial is multi-pages and does it have the right tone?

<Howard> bye - thank you

Shawn: Remind us to email so all of those even not on the call can be alerted to review.

<paulschantz> bye!

Shawn: check agenda items, actions list, and update availability.