Update checklist #779
Update checklist #779
Conversation
ericwbailey
added
enhancement
|
Looks great, @ericwbailey! The extra content pieces at the top are a fantastic addition. Curious if we should add some checkbox elements, to add that "checklist" feel? Otherwise, perhaps we should call it something else? |
|
thoughts on marking these up as a standard lists, but using details / summary (or ARIA disclosures) to show/hide the content? I ask for a couple reasons:
re: the above two points, if checkboxes are used somehow, i'd expect they be in a visual manner. It would be odd to have checkboxes and controls to show/hide. If we don't go with the disclosure widget route and do re-introduce checkboxes, let's just keep it simple. There's no reason to reintroduce the |
|
+1 native disclosure. Would save a ton of space and would help the content be less overwhelming which is sort of the point. |
|
No problems here going with a native disclosure. I'll get on that soon. |
|
Pushed up a new version with copy edits and a treatment using
|
|
I'm one of those people who can't build the site... so thanks for the
screengrab.
I've got a few comments I'd like to make about readability and
understandability - could someone cut and paste the whole page into a
google doc for these types of comments??
regards
Jonathan Holden
…On Sun, 28 Apr 2019 at 19:02, Eric Bailey ***@***.***> wrote:
This PR:
- Removes the form. Checking off checklist items does not create a
situation where data will be submitted—if we want a persistent checked
state, we should use a more modern solution such as localStorage.
- Removes garlic.js <https://garlicjs.org/> to reflect this.
- Adds some context about why the checklist exists, as well as links
to resources to use to test.
- Most importantly, there is a significant content update to the
checklist items, reflecting @svinkle <https://github.com/svinkle>'s
efforts to better steer people towards AA compliance. Each checklist item
now has a pertinent success criterion, description, and links where
appropriate. The checklist sections have been expanded, as well.
This PR won't interfere with redesign efforts, as the checklist's place in
the site's information architecture won't be moving.
I know it's a good amount of content to review, but I'd personally love it
if we could get this updated by Global Accessibility Awareness Day
<https://globalaccessibilityawarenessday.org/> (May 16th). I also know
some people have been having difficulty building the site, so here's a
screenshot
<https://user-images.githubusercontent.com/634191/56867560-7e916b80-69b4-11e9-82c0-17f831b82058.png>
.
Also tapping @nas5w <https://github.com/nas5w> and @sebacicltd
<https://github.com/sebacicltd>, for concerns expressed in #736
<#736>.
------------------------------
You can view, comment on, or merge this pull request online at:
#779
Commit Summary
- Update checklist content
- Add checklist styling
- Remove garlic
- Add checklist separators
File Changes
- *M* _layouts/default.html
<https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-0>
(1)
- *A* _sass/_checklist.scss
<https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-1>
(54)
- *M* checklist.html
<https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-2>
(654)
- *M* css/master.scss
<https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-3>
(1)
- *M* js/scripts.js
<https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-4>
(2)
Patch Links:
- https://github.com/a11yproject/a11yproject.com/pull/779.patch
- https://github.com/a11yproject/a11yproject.com/pull/779.diff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#779>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ALAHQIUWZ6HVHC6G3XBOERTPSXKB3ANCNFSM4HI65YEQ>
.
|
|
I'm also interested in WHO has responsibility for each of these "checkbox"
items during web design and build.
On a one person team, that's easy enough - but of course we need to "teach"
the client how to write good content. And we need to explain why we can't
use their logo colour for buttons (for example, contrast).
On a larger team, responsibility may fall to different people, and being
able to divide up the checklist according to role would be really helpful.
Clearly defining responsibility at the start of the project would help
execution a lot, I think.
regards
Jonathan Holden
On Mon, 29 Apr 2019 at 09:14, Jonathan Holden <jonathan@sebacic.co.uk>
wrote:
… I'm one of those people who can't build the site... so thanks for the
screengrab.
I've got a few comments I'd like to make about readability and
understandability - could someone cut and paste the whole page into a
google doc for these types of comments??
regards
Jonathan Holden
On Sun, 28 Apr 2019 at 19:02, Eric Bailey ***@***.***>
wrote:
> This PR:
>
> - Removes the form. Checking off checklist items does not create a
> situation where data will be submitted—if we want a persistent checked
> state, we should use a more modern solution such as localStorage.
> - Removes garlic.js <https://garlicjs.org/> to reflect this.
> - Adds some context about why the checklist exists, as well as links
> to resources to use to test.
> - Most importantly, there is a significant content update to the
> checklist items, reflecting @svinkle <https://github.com/svinkle>'s
> efforts to better steer people towards AA compliance. Each checklist item
> now has a pertinent success criterion, description, and links where
> appropriate. The checklist sections have been expanded, as well.
>
> This PR won't interfere with redesign efforts, as the checklist's place
> in the site's information architecture won't be moving.
>
> I know it's a good amount of content to review, but I'd personally love
> it if we could get this updated by Global Accessibility Awareness Day
> <https://globalaccessibilityawarenessday.org/> (May 16th). I also know
> some people have been having difficulty building the site, so here's a
> screenshot
> <https://user-images.githubusercontent.com/634191/56867560-7e916b80-69b4-11e9-82c0-17f831b82058.png>
> .
>
> Also tapping @nas5w <https://github.com/nas5w> and @sebacicltd
> <https://github.com/sebacicltd>, for concerns expressed in #736
> <#736>.
> ------------------------------
> You can view, comment on, or merge this pull request online at:
>
> #779
> Commit Summary
>
> - Update checklist content
> - Add checklist styling
> - Remove garlic
> - Add checklist separators
>
> File Changes
>
> - *M* _layouts/default.html
> <https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-0>
> (1)
> - *A* _sass/_checklist.scss
> <https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-1>
> (54)
> - *M* checklist.html
> <https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-2>
> (654)
> - *M* css/master.scss
> <https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-3>
> (1)
> - *M* js/scripts.js
> <https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-4>
> (2)
>
> Patch Links:
>
> - https://github.com/a11yproject/a11yproject.com/pull/779.patch
> - https://github.com/a11yproject/a11yproject.com/pull/779.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#779>, or mute the
> thread
> <https://github.com/notifications/unsubscribe-auth/ALAHQIUWZ6HVHC6G3XBOERTPSXKB3ANCNFSM4HI65YEQ>
> .
>
|
|
I like this idea, though I wonder how might be the best way to surface this, as many checklist items should be everyone's responsibility, to some degree. |
|
Scott
I'm not so sure. The content writers have no responsibility for the skip
link. Then colour contrast of buttons and links is the responsibility of
the designer. Image alt tags? The system has to be set up to accept them
(ok, that's built in to WordPress for example) , and then it's down to the
person who uploads the images to tag them appropriately.
I feel that allowing the project manager to delegate specific tasks may
raise overall compliance as there will be less opportunity for people to
assume that "someone else will do that".
…On Mon, 29 Apr 2019, 16:53 scottaohara, ***@***.***> wrote:
I like this idea, though I wonder how might be the best way to surface
this, as many checklist items *should* be everyone's responsibility, to
some degree.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#779 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALAHQIWT5J35O7VU6RYL2LLPS4DX7ANCNFSM4HI65YEQ>
.
|
|
@sebacicltd as stated "to some degree". Per even your examples: skip link requires a design and expected behavior (does it remain positioned, or does it become static? how does this surface on small screens where iOS doesn't reveal visually hidden skip links on focus. developers then need to implement appropriately). colo(u)r contrast is initially a designers responsibility to provide, but dev and or QA should be empowered to verify implementing. Especially if using a component library where individual elements may be fine in isolation, but issues may become apparent in implementation. Images being uploaded to a CMS may not be by the person who is in charge of how they'd be used. e.g. interns doing the grunt work of optimizing for web and getting content uploaded may have no background in providing appropriate alt text. Is the image used in one instance as decorative and another as informative? Who makes that call and who can be on call to check so as to not have a single point of failure. |
|
I'll get a Google doc with the content soon, @sebacicltd. Appreciate you taking a look. Point of order: while we're discussing the responsibility topic, do we agree that it's not a blocker for merging the updated checklist content? I think we can start a new issue if and when this is merged, then potentially add in content from there. |
|
Responsibility..... Absolutely not blocking anything.... Every project is
different, so it will be up to the project manager to decide in each case.
(it's just very pertinent to me personally at the moment)
…On Mon, 29 Apr 2019, 19:27 Eric Bailey, ***@***.***> wrote:
I'll get a Google doc with the content soon, @sebacicltd
<https://github.com/sebacicltd>. Appreciate you taking a look.
Point of order: while we're discussing the responsibility topic, do we
agree that it's not a blocker for merging the updated checklist content? I
think we can start a new issue if and when this is merged, then potentially
add in content from there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#779 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALAHQISRO2S6M455PQ6WFJLPS4VZNANCNFSM4HI65YEQ>
.
|
|
Great. Here's that content doc I promised, it's currently set to read and suggest mode. |
|
I'm still working through the doc, but these are some great edits so far. Thank you for doing them, @sebacicltd. |
|
I'll take a look in the morning to see if you have any questions, but I'm
sure you know more about this than I do!
…On Tue, 30 Apr 2019, 22:22 Eric Bailey, ***@***.***> wrote:
I'm still working through the doc, but these are some great edits so far.
Thank you for doing them, @sebacicltd <https://github.com/sebacicltd>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#779 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALAHQIXPIWFSW2S55OVUSX3PTCTAFANCNFSM4HI65YEQ>
.
|
|
Just pushed up changes reflecting @sebacicltd's work. |
checklist.html
Outdated
| </p> | ||
| <h3 id="does-this-checklist-guarantee-my-site-is-accessible">Does this checklist guarantee my site is accessible?</h3> | ||
| <p> | ||
| No. However, working through this checklist will help greatly improve the experience for everyone who uses your site. The issues it prompts you to check for covers a wide range of disability conditions. | ||
| No. However, using this checklist will help improve the experience for everyone who uses your site. The issues it prompts you to check for covers a wide range of disability conditions. |
There was a problem hiding this comment.
again success criterion or issues?
checklist.html
Outdated
| <details id="section-headings-01"> | ||
| <summary> | ||
| Use headings elements to describe headings. | ||
| Use heading elements to describe headings. |
There was a problem hiding this comment.
Use heading elements to introduce content
|
Unless there's any more feedback, I will merge this on Saturday to provide some time for people to review it on the live site before we announce it on Wednesday. |
checklist.html
Outdated
| <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html">1.3.1 Info and Relationships</a> | ||
| </p> | ||
| <p class="checklist-description"> | ||
| This prevents a Internet Explorer from allowing focus to navigate through the child elements of an SVG that is meant to be decorative. |
There was a problem hiding this comment.
This prevents
aInternet Explorer
checklist.html
Outdated
| <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html">2.1.2 No Keyboard Trap</a> | ||
| </p> | ||
| <p class="checklist-description"> | ||
| This solves a bug in Safari which interferes with VoiceOver describing <code>svg</code> images that contain the <code>use</code> element. |
There was a problem hiding this comment.
interferes with VoiceOver describingcan sometimes create hidden tab-stops when navigatingsvg
checklist.html
Outdated
| <a href="https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html">1.3.5 Identify Input Purpose</a> | ||
| </p> | ||
| <p class="checklist-description"> | ||
| <a href="https://www.w3.org/TR/html52/sec-forms.html#sec-autofill">Providing a mechanism</a> to help people more quickly, easily, and accurately fill in form fields that ask for common information (for example, name, address, phone number). Ensure that form input errors are displayed in a list above the form after the form is submit |
There was a problem hiding this comment.
Ensure that form input errors are displayed in a list above the form after the form is submit ted.
|
Two points I feel like are missing from the old list:
We could expand these to include |
|
Thanks @svinkle. I've added them to the Controls section, starting here: https://github.com/a11yproject/a11yproject.com/pull/779/files#diff-f716bc61caf8adb552960a60746bd411R478 |
| <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html">1.3.1 Info and Relationships</a> | ||
| </p> | ||
| <p class="checklist-description"> | ||
| Terms like "click here" and "read more" do not provide any context. Some people navigate using a list of all buttons or links on a page or view. When using this mode, the terms indicate what will happen if navigated to or activated. |
There was a problem hiding this comment.
consider:
Terms like "click here" and "read more" do not provide adequate context for what they will do. Some people navigate using a listing of all buttons or links on a page or view. When navigating in this way, its more helpful if these elements indicate what will happen if they're interacted with. e.g. "Learn more about accessibility" rather than just "Learn more".
There was a problem hiding this comment.
I like this, but I'd also like to update it to include the cognitive angle, in that it's less ambiguous to all people, regardless of browsing mode.
checklist.html
Outdated
| </summary> | ||
| <div class="checklist-details"> | ||
| <p class="checklist-criterion"> | ||
| <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html">3.2.2 On Input</a> |
There was a problem hiding this comment.
Not doing this would not actually fail this SC. more of an advisory technique / best practice, which is actually indicated in the understanding link, which then links to: https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G201
There was a problem hiding this comment.
Is there another SC it would fail?
There was a problem hiding this comment.
i don't think so. More of a best practice. Especially regarding external links.
There was a problem hiding this comment.
So I think our options here are to:
- Leave it be and have the SC be a little bit of a white lie, because it is an important thing to think about.
- Remove it, as it's not technically a failure, which is not in keeping with our other checklist items.
- Add a note to the end about what you mentioned, which I think kind of is like the second option.
I'm personally leaning towards removal. I want this checklist to be airtight.
There was a problem hiding this comment.
I think this could stay in if you remove mentioning external links. Opening in a new window you could link over to http://www.w3.org/TR/WCAG20-TECHS/G201.html as a reasoning/ technique
| <div class="checklist"> | ||
| <details id="section-tables-01"> | ||
| <summary> | ||
| Use the <code>table</code> element to describe tabular data. |
There was a problem hiding this comment.
Use the table element to markup tabular data.
checklist.html
Outdated
| <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html">2.1.1 Keyboard</a> | ||
| </p> | ||
| <p class="checklist-description"> | ||
| Provide a global pause function on any media control. If the device has a keyboard, ensure that pressing the <kbd>Space</kbd> key can pause playback. |
There was a problem hiding this comment.
Provide a global pause function on any media element that can be played.
we need to be careful with:
ensure that pressing the Space key can pause playback.
Since space key should allow for the viewport to scroll, when not focusing a form control of some type, we don't want to make people think it's always ok to overwrite this functionality and disallow its inherent behavior.
typically the space key should allow for a "global pause" only when keyboard focus is within the context of a larger media grouping, and where space shouldn't also be expected to activate other interactive elements which are focused.
There was a problem hiding this comment.
Would a followup sentence along the lines of, "Make sure you also don't interfere with the Space key's ability to scroll the page/view when not focusing on a form control." work for you?
There was a problem hiding this comment.
mmm. maybe. I think using the term "global" is still misleading though. The Space key should really only work in the context of the media group.
There was a problem hiding this comment.
Let's remove the reference to a global function, then:
Provide the ability to pause any media control. If the device has a keyboard, ensure that pressing the Space key can pause playback. Make sure you also don't interfere with the Space key's ability to scroll the page/view when not focusing on a form control.
Sound good?
There was a problem hiding this comment.
a lot better. The only thing that is stands out to me now is calling it a "media control". Swap out "control" with "element" and i think this is good to go.
|
Merged. If there's further feedback let's address it on an Issue by Issue basis. |
|
Awesome work @ericwbailey and @scottaohara! 👏 I feel like we'll be able to improve upon this over time in a variety of ways. Perhaps by providing "further reading" links for more info and code snippets within the For example, to help with the Viewport list item, we could show what to do and what not do to:
<meta name="viewport" content="initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no">
<meta name="viewport" content="width=device-width, initial-scale=1">The content that we have now is great, but doesn't really explain what exactly to look for or how to solve the issue. I'm just thinking if someone new to all of this reads the list, it may lead to more questions. |
|
I think that's a good idea for some of these that lend themselves to simple code dos/don'ts. Was also just thinking this might provide us a bit of a road map on additional informative posts to add to the site as well. |
This PR:
localStorage.This PR won't interfere with redesign efforts, as the checklist's place in the site's information architecture won't be moving.
I know it's a good amount of content to review, but I'd personally love it if we could get this updated by Global Accessibility Awareness Day (May 16th). I also know some people have been having difficulty building the site, so here's a screenshot.
Also tapping @nas5w and @sebacicltd, for concerns expressed in #736.