Reference: http://w3c.github.io/wai-quick-start/designing.html#ensure-that-form-elements-include-clearly-associated-labels

This is a follow up to #739 and #738.

To be consistent with the proposed changes in the title and wording of the tip, I would change the way the example form is laid out, so the labels are sitting right above the form elements, instead of the left. I would leave the checkbox as is, but maybe align it with the rest of the stack by pushing it to the right a little.

For Editors discretion.

Suggest changing "If it is a government website, contact your local government." to "If it is a government website, contact your local government representative." (or parliamentarian? but not usually an appropriate term for municipal government)

Can we make these more visible?

At a minimum, can we add a space between the word and the arrows?

Instead of saying:

"Provide distinct styles for interactive elements, such as links and buttons, to make them easy to identify. For example, change the appearance of links on mouse hover, keyboard focus, and touch-screen activation. Ensure that styles and naming for interactive elements are used consistently throughout the website."

I suggest we make the following change:

"Provide distinct styles for interactive elements, such as links and buttons, to make them easy to identify. For example, provide a clearly visible focus indicator to change the appearance of links on mouse hover, keyboard focus, and touch-screen activation. Ensure that styles and naming for interactive elements are used consistently throughout the website."

(Just so it emphasizes the importance of providing visible focus indicators when navigating with the keyboard - that loops in 2.4.7)

Thelonius Mank

Example of simple policy
ACME Inc. is committed to ensuring that its website is accessible to people with disabilities. All the pages on our website will meet W3C WAI’s Web Content Accessibility Guidelines 2.0, Level AA conformance. Report any issues to [email protected].

Do we want to change

[email protected]

to

[email protected]

or such?

Maybe include something along the lines of: The Before and After Demonstration (BAD) includes reports on how each page conforms to WCAG 2.0. For example, see the Inaccessible Home Page Report.

From @nitedog

For later (please log somewhere):
Something odd about pointing out individual personas and videos with older people. For example, the captions video is also relevant to older people, even if it doesn't happen to feature anyone. Maybe we just need some explanatory sentence about universal design, or maybe reference to accessibility/usability/inclusion page when ready.

From @AndrewArch

re the Resize text check, can we say anything about page that don't 'pinch-zoom' on mobile devices? Maybe record in backlog for next review?

Shawn agrees to consider adding this.

pros and cons to both approaches.

probably good to have the same throughout the document.
(consistency is generally best... although mixin' it up has advantages in some situations...

Attached file has Comments and tracked changes for consideration.

selecting-eval-tools.docx

more like this -- at least so the hanging indents / left margins are the same alignment

When the new Mobile Accessibility Introduction is done -- or maybe even when it's a polished draft -- add clear pointers to it.

Reference: http://w3c.github.io/wai-quick-start/designing.html#provide-clear-and-consistent-navigation-options

The tip currently reads: "Ensure that navigation across pages within a website has consistent naming, styling, and positioning. Provide more than one method of website navigation, such as a site search or a site map. Help users understand where they are in a website or page by providing orientation cues, such as breadcrumbs and clear headings".

I propose the following edits: "Ensure that navigation across pages within a website has consistent naming, styling, and positioning. Provide more than one method of website navigation beyond the main navigation menu, such as a site search or a site map. Help users understand where they are in a website or page by providing orientation cues, such as breadcrumbs and meaningful headings".

At a high level, where in the existing site content should we begin to integrate mobile-specific information? For example: tutorials, Tips for Getting Started, etc.

This could be used in multiple places to make it easy to find the code where there are good practice ideas.

https://app.zeplin.io/project.html#pid=58da7fb05d831f2441ed1c0a&sid=58da800524555267b14fa6be

think about what to say about the article.

want to provide credibility.

Take a pass at adding one or two word "handles" to make the list of Tips easier to parse.

Example of possible "handles" for https://w3c.github.io/wai-website/tips/writing/

• Page titles — Provide informative, unique page titles
• Headings — Use headings to convey meaning and structure
• Links — Make link text meaningful
• Alt text — Write meaningful text alternatives for images
• Multimedia — Create transcripts and captions for multimedia
• Instructions — Provide clear instructions
• Concise — Keep content clear and concise
• Learn More — Learn more about accessibility

This suggestion is in response to Oct 2017 usability testing.

Have left side Related Links section include all 6 Tips pages?

I'd like to suggest that the following statement is problematic, and that it be readjusted.

"Use combined expertise: Evaluating web accessibility requires diverse kinds of skills and expertise. For example, some requirements relate to the design, writing, and development aspects of a website, while others relate to assistive technologies and their use by people with disabilities. Sharing evaluation tasks in a team of reviewers can help make evaluation more effective and efficient.
Learn more" http://www.w3.org/WAI/eval/reviewteams

We had long discussions about this on the Evaluation Methodology task force. Here are the issues:

• The statement puts unfair emphasis on multi member teams and large consultancy houses, and disadvantages accessibility consultants. It give the perception that a large accessibility house provide better coverage than a knowledgeable consultant.
• Even the large accessibility houses assign one assessor to a project. Even if they have 25-50 accessibility testers, they don't assign multiple assessors to a project. It's not practical and doesn't usually provide better results.
• The link provided goes to an article that is over 15 years old. It is dated and is not how the industry has developed.
• Note: Of course usability testing with people with disabilities with AT is important, and should be conducted but I don't think we should conflate that with a conformance audit, although it is often incorporated into an audit. I think that could be included as a separate bullet point.

Here is the language we used in the Evaluation Task force:

Combined Expertise (Optional)
This methodology can be carried out by an individual evaluator with the skills described in the previous section (Required Expertise), or a team of evaluators with collective expertise. Using the combined expertise of different evaluators may sometimes be necessary or beneficial when one evaluator alone does not possess all of the required expertise. ...

Reference: http://w3c.github.io/wai-quick-start/designing.html#ensure-that-interactive-elements-are-easy-to-identify

The quick tip currently reads: "Provide distinct styles for interactive elements, such as links and buttons, to make them easy to identify. For example, change the appearance of links on mouse hover, keyboard focus, and touch-screen activation. Ensure that styles and naming for interactive elements are used consistently throughout the website."

I suggest we make a few small changes, to read: "Provide distinct styles for interactive elements, such as links and buttons, to make them easy to identify visually. For example, change the appearance of links on mouse hover, keyboard focus, and touch-screen activation. Ensure that styles and naming for interactive elements are used consistently throughout the website to help users recognize common patterns."

After having given it some thought, I am uncomfortable with using the terms "user stories" in our quick tips to link to the content from the "How people use the Web" resource. I would be in favor of changing "User story" to "Persona", which I think is much closer to what we're conveying, here. While these are stories about users, that particular term has been deviated from its original meaning in Agile to mean the description of a requirement, based on the expectation of a person using the site/app/software/etc.

In most designers' and developers' minds nowadays, the expectation of a user story is likely to be related to a very high-level definition of a requirement or a feature, in the form of "as a [x], I want/need [y], so that I can [z]". This is not what we're providing here. I think it's misleading, and I think we'D be better of avoiding that confusion if we can.

So this a global proposal to replace "User story" by "Persona", on every tip that links to one:

Designing

• https://www.w3.org/WAI/gettingstarted/tips/designing.html#provide-sufficient-contrast-between-foreground-and-background
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#dont-use-color-alone-to-convey-information
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#ensure-that-interactive-elements-are-easy-to-identify
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#provide-clear-and-consistent-navigation-options
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#ensure-that-form-elements-include-clearly-associated-labels
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#provide-easily-identifiable-feedback
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#use-headings-and-spacing-to-group-related-content
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#create-designs-for-different-viewport-sizes
• https://www.w3.org/WAI/gettingstarted/tips/designing.html#include-image-and-media-alternatives-in-your-design

Developing

• https://www.w3.org/WAI/gettingstarted/tips/developing.html#include-alternative-text-for-images
• https://www.w3.org/WAI/gettingstarted/tips/developing.html#use-mark-up-to-convey-meaning-and-structure
• https://www.w3.org/WAI/gettingstarted/tips/developing.html#help-users-avoid-and-correct-mistakes
• https://www.w3.org/WAI/gettingstarted/tips/developing.html#write-code-that-adapts-to-the-users-technology
• https://www.w3.org/WAI/gettingstarted/tips/developing.html#ensure-that-all-interactive-elements-are-keyboard-accessible

Writing

• https://www.w3.org/WAI/gettingstarted/tips/writing.html#use-headings-to-convey-meaning-and-structure
• https://www.w3.org/WAI/gettingstarted/tips/writing.html#write-meaningful-text-alternatives-for-images
• https://www.w3.org/WAI/gettingstarted/tips/writing.html#create-transcripts-and-captions-for-multimedia
• https://www.w3.org/WAI/gettingstarted/tips/writing.html#provide-clear-instructions
• https://www.w3.org/WAI/gettingstarted/tips/writing.html#keep-content-clear-and-concise

Priority: Medium
Location: Introduction paragraph
Current Wording:

This document presents a recommended format for communicating results of the evaluation of Web site accessibility according to the Web Content Accessibility Guidelines (WCAG) 2.0. A consistent and comprehensive evaluation report format can help ensure effective evaluations as well as accurate comparisons of accessibility levels over time and between different Web sites.

Suggested Revision:

This document presents a recommended format for communicating results of the evaluation of Web site or Web application accessibility according to the Web Content Accessibility Guidelines (WCAG) 2.0. A consistent and comprehensive evaluation report format can help ensure effective evaluations as well as accurate comparisons of accessibility levels over time and between different sites and applications.

Rationale: Want users to know that this eval report can be used for reporting on web apps as well as web sites.

From @slhenry comment in w3c/wai-quick-start#266.

On overview page, especially when there's only the first row of pages, the box stands out too much, I think. What about making the font smaller? and/or lighter?

Comment received from Jordan Wilson [email protected].

I don't find this to be a useful design tip:
Provide alternative text for images
I believe that's a very useful content (copywriter) tip and a very useful developer tip. I've found that for designers this just gets ignored because its not part of their job role. Instead I convey it differently:

Non-text content (imagery, sound, video) need an appropriate text-alternative
When your design includes imagery, sound or video consider how it will be conveyed to a user unable to perceive visible or audible content. Video or sounds will need a transcript, captions or audio descriptions. The design should provide a way to access those resources. Consider if your visual assets are informational (ex. important imagery, images of text or a chart) or decorative (ex. a separator or 'smiling businessperson' photography). Communicate with writers and developers to convey those needs.

https://www.w3.org/WAI/intro/components -> https://www.w3.org/WAI/intro/components.php

Priority: Medium

Location: Flashing or Blinking content

Suggested:
Include an example image of what three flashes per second looks like. This could be a simple animated GIF (or SVG?!). This may need to be hidden behind an expand/collapse so people can chose specifically if they want to see it.

Rationale: It is arguably difficult to know what three flashes per second looks like and it may be than an example or two would help evaluators gain an idea what they are looking for.

@michael-n-cooper & Judy

Should https://www.w3.org/TR/html-aria/

be listed in the ARIA Overview page and in https://www.w3.org/TR/#tr_Accessibility__All_

?

This will be based on the Managing list we already have

It probably would be better to have the buttons before the slides. It was more complicated from a CSS point of view but nowadays we could probably reposition the buttons using grid or flexbox.

Reference: http://w3c.github.io/wai-quick-start/designing.html#provide-sufficient-contrast-between-foreground-and-background

I suggest we add additional information for screen reader users to understand the examples better. For example, the <figcaption> text for the insufficient example currently reads:

<figcaption>
<svg class="cross" aria-hidden="true">
<use xlink:href="images/icons.svg#cross">
</svg>
Insufficient
</figcaption>

I suggest we provide additional context:

<figcaption>
<svg class="cross" aria-hidden="true">
<use xlink:href="images/icons.svg#cross">
</svg>
Insufficient
<div class="hidden-accessible">This example shows light grey text on a white background.</div>
</figcaption>

Likewise, the other example for sufficient contrast currently reads:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Sufficient
</figcaption>

I suggest we provide additional context:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Sufficient
<div class="hidden-accessible">This example shows light grey text on a white background.</div>
</figcaption>

Where "hidden-accessible" would refer to the following CSS rules:

.hidden-accessible {
     border: 0; 
     clip: rect(0 0 0 0); 
     height: 1px; 
     width: 1px; 
     margin: -1px; 
     padding: 0; 
     overflow: hidden; 
     position: absolute;
}

Reference: http://w3c.github.io/wai-quick-start/designing.html#ensure-that-interactive-elements-are-easy-to-identify

I suggest we add additional information for screen reader users to understand the examples better. Currently, the <figcaption> text for the examples read:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Style links to stand out from text
</figcaption>

I suggest we provide additional context:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
<div class="hidden-accessible">Good example using</div>
Style links to stand out from text
</figcaption>

Where "hidden-accessible" would refer to the following CSS rules:

.hidden-accessible {
     border: 0; 
     clip: rect(0 0 0 0); 
     height: 1px; 
     width: 1px; 
     margin: -1px; 
     padding: 0; 
     overflow: hidden; 
     position: absolute;
}

The same could be applied to the following examples:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Mouse hover style
</figcaption>

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Keyboard focus style
</figcaption>

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Touch or click style
</figcaption>

Re: Issue w3c/wai-tutorials#377

The first thing screen readers say when the user goes to a different web page is the page title. Page titles are important for orientation — to help users know where they are and move between open pages.

Would it be useful to have a sound clip of the screen reader going through page titles? Low priority, but maybe neat for people who don't know screen readers?

Generally favor the approach, but it is problematic due to current status of UI components library. If the curation problem is solved, this could be written to be consistent with the "How To Use..." approach of Mobile and ARIA. Focus may then not be on datepicker alone but discussion could include others as well.

Looking at the code snippet on
https://www.w3.org/WAI/tutorials/page-structure/example/

It shows the main starting with an article, and the first thing in the article is a TOC.

At least for screen reader and keyboard users, the best use of main is to draw the user right into the main content in the same way that good visual design brings gaze to the most important content. There is nothing worse, as a screen reader user, then having to skip past a bunch of links at the start of main, especially if the main content is an article. And, there is nothing better than a site that uses main well.

Ideally, the first thing in main is a heading immediately followed by content. If there is stuff between the heading and the main content, then a good work around is to put the heading outside of main and have it label main. Then, when you jump to main you get the benefit of hearing that main is what you expect and then you dive right into the meat ... 0 wasted time.

An article TOC, if part of the design, can be in a nav outside of main. However, TOCs for the main content of the current page are a rare entities because they only provide value on extremely long pages, which aren't all that common ... except on w3.org, of course.

Similarly, it is also best if breadcrumb nav regions are outside of main.

The current title and description reads as:

Ensure that form elements include clearly associated labels
Ensure that all fields have a descriptive label adjacent to the field. For left-to-right languages, labels are usually positioned to the left or above the field, except for checkboxes and radio buttons where they are usually to the right. Avoid having too much space between labels and fields.

We would like to cover the following ideas more clearly in this quick tip:

• Programmatically associating the label with the field (SC 1.3.1)
• Ensuring that the label is visible at all times (SC 3.3.2)
  -- Under the WCAG label definition, the following is given to ensure labels are presented to all users (including sighted users): “Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.”
• Make the tip more international by removing reference to left-to-right languages.

Proposed changes:

Ensure that form elements include programmatically associated labels
Ensure that each field has a programmatically linked and descriptive label in close proximity to that field. Labels should remain visible at all times and placed above its field, except for checkboxes and radio buttons where they are usually positioned to the side.

Reference: http://w3c.github.io/wai-quick-start/designing.html#ensure-that-form-elements-include-clearly-associated-labels

This is a follow up to #739.

The tip currently reads: "Ensure that all fields have a descriptive label adjacent to the field. For left-to-right languages, labels are usually positioned to the left or above the field, except for checkboxes and radio buttons where they are usually to the right. Avoid having too much space between labels and fields."

A couple of things don't quite work for me here.

1. I understand why we mention the whole left-to-right languages, but it's overly complicated for no real value. Since the content is written in English and we're already not providing recommendations for any other type of language directions, I think we should just remove that part.
2. For proximity issues and to provide the best stack possible (including on mobile), I would make a recommendation to favor visible labels, positioned right above the field, not to the left. Except for radio buttons and checkboxes of course).
3. Because our tips are meant to be as straightforward as possible, I would not mention anything about the special snowflakes covered in H65 for moments when it's ok to have hidden labels.
4. The last sentence "Avoid having too much space between labels and fields" is too vague. I think we can fix that by being a little more prescriptive in our tip. I would lose that sentence entirely.

Based on arguments explained in issue 321, and the ones above, I would suggest we change the wording of this tip, to: "Ensure that all form elements have a descriptive label adjacent to it. For proximity concerns, it is recommended to position the labels right above the fields, except for checkbox and radio button labels, which are usually positioned to the right of the form elements."

The change made yesterday introduced bad HTML to the Accessibility Intro page. As I went lengths to clean up bad HTML, that was present on most of the old pages, please provide proper HTML5.

https://validator.w3.org/nu/?doc=http%3A%2F%2Fw3c.github.io%2Fwai-website%2Ffundamentals%2Faccessibility-intro%2F

• Using acronym
• having a shape="rect" attribute on a elements

We need an approach for packaging changelogs and resource descriptions (like requirements analysis) with each resource, so we can consistently link to is and reliably find it. Maybe using the README files on GitHub could work, or wikis or pages in the resource.

Prompted by: w3c/wai-older-users#12 (comment)

Reference: http://w3c.github.io/wai-quick-start/designing.html#dont-use-color-alone-to-convey-information

I suggest we add additional information for screen reader users to understand the examples better. Currently, the <figcaption> text for the failed examples read:

<figcaption>
<svg class="cross" aria-hidden="true">
<use xlink:href="images/icons.svg#cross">
</svg>
Color only
</figcaption>

I suggest we provide additional context:

<figcaption>
<svg class="cross" aria-hidden="true">
<use xlink:href="images/icons.svg#cross">
</svg>
<div class="hidden-accessible">Bad example using</div>
Color only
</figcaption>

Likewise, the examples for valid implementation read:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
Color and symbol
</figcaption>

I suggest we provide additional context:

<figcaption>
<svg class="tick" aria-hidden="true">
<use xlink:href="images/icons.svg#tick">
</svg>
<div class="hidden-accessible">Good example using</div>
Color and symbol
</figcaption>

Where "hidden-accessible" would refer to the following CSS rules:

.hidden-accessible {
     border: 0; 
     clip: rect(0 0 0 0); 
     height: 1px; 
     width: 1px; 
     margin: -1px; 
     padding: 0; 
     overflow: hidden; 
     position: absolute;
}

Reference: http://w3c.github.io/wai-quick-start/designing.html#ensure-that-form-elements-include-clearly-associated-labels

The tip title currently reads: "Ensure that form elements include clearly associated labels". I don't like the way this is worded for a couple of reasons:

1. We are using the word "clearly" while in reality, what we probably meant was "programmatically". I understand why we would want to stay away from such a mouthful of a word, but I don't feel that "clearly" conveys the same intent.
2. Assuming we're also suggesting what we consider acceptable/recommendable best practices that may go beyond what a Success Criterion actually requires, I would advocate for asking for a visible label here, even if H65 informs us that sometimes, it's ok to only provide a hidden label.
3. Knowing that implicit labels are also acceptable as per WCAG, I would still prefer to use the word "explicitly", as it conveys the idea of programmatic association a little better than "clearly" does.
4. Another aspect that we're not highlighting strongly enough is the idea of labels and form elements to be in close proximity. My revised title also addresses this.

Based on the arguments above, I propose we change the title of this tip to: "Ensure that visible labels are explicitly associated, and in close proximity of their corresponding form elements".

Understand issues and what we want to do with clearing it and/or auto-populating it -- or disabling it.

(some surprising stuff in there already)

Reference: http://w3c.github.io/wai-quick-start/designing.html#provide-sufficient-contrast-between-foreground-and-background

The description of this quick tip ends with a sentence that says: "Contrast ratio is a short version of the more technically correct term luminance contrast ratio". Having taken part in the "Easy Checks" discussions a few years ago, I understand where that last sentence about luminance is coming from, but this is way too subtle for anyone who's new to accessibility. In order to remain true to our goal of addressing readers in layman's terms, I suggest we remove the last sentence entirely. I don't think it brings any real value to someone who would be new to accessibility.

I preface this issue/comment with the understanding that there is a timing issue of UICL probably not being completed before this tutorial would be completed.

Would the example of the datepicker and/or datepicker features and styling be straight from one of the submitted datepickers in the UICL? (I am guessing not because the components list may not be in published form in time) But also, I am thinking that we would not want to single out one specific submitted datepicker over another one. To me this means that we would just build a tutorial on a newly developed example of a datepicker and then could update the tutorial with all of the UICL "how tos" and examples.

How would the timing of this all work out? I like the idea of a tutorial that shows off and links to the UICL, but how do we address the timing?

Reference: http://w3c.github.io/wai-quick-start/designing.html#provide-easily-identifiable-feedback

The tip currently reads:

Provide easily identifiable feedback
Provide feedback for interactions, such as confirming form submission, alerting the user when something goes wrong, or notifying the user of changes on the page. Instructions should be easy to identify. Important feedback that requires user action should be presented in a prominent style.

Proposing we change to:

Provide easily identifiable feedback
Provide feedback for interactions, such as confirming form submission, alerting the user when something goes wrong, or notifying the user of changes on the page. Instructions should be easy to identify and suggestions to help fix issues whenever errors are returned must be provided. Important feedback that requires user action should be presented in a prominent style.

Either:

• Add a specific example to the decorative images page (my rec), or
• Remove the case from the decision tree.

See this discussion:
https://twitter.com/MichielBijl/status/836921857211236352