Nav: EOWG wiki main page > Evaluation Pages

This is an old archive of the Easy Checks wiki page

Easy Checks - A First Look at Web Accessibility

Related pages:

To Do

Page titles

[OPEN action] Find a keyboard way to display the full page title in IE 9 and later and chrome.

Keyboard access and visual focus

[EOWG thoughts?] Is it specific and clear enough to write: "To select a specific item within an element such as a drop-down list, press the Enter key or Space bar."
[EOWG thoughts?] In "what to do", visual focus:
"Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted. (A common problem is that the default focus indicator is turned off in CSS [@@ too jargony?] or elements are styled with borders that overlap or hide the focus indicator.)"

Forms and error messages

[EOWG thoughts?] In "required fields" we may need to explain group label in the beginning.
[OPEN action] In "error messages", need to say more specifically how to check if the focus is at the error message.

Multimedia (video, audio) alternatives

[OPEN action] In Section "captions", look for a way to turn on open captions with the keyboard, for example in Youtube activating the CC button.
[EOWG thoughts?] think of other examples for important noise, especially positive ones (instead of slamming and breaking:)

Throughout:

Check img alts - some might have @@
Decide if we want more images for the steps. Search for [image].
Search for other open things in [brackets].
Search throughout for the perspective that the content needs to work, rather than the user has a limitation. e.g., 'users need to be able to' vs. 'websites need to enable users to' {Shawn}

Misc:

Ask Identifying Web Accessibility Issues to link to Easy Checks when it's more done.

Overall Comments

Any edits based on input from Tom J. (Wayne's forwarded e-mail) ?
- comment {name}
- [in-progress] I agree with Tom's following thought:
  "Looking for an even simpler FIRST check, I've tried this one:
  FF Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images With Alt Attributes; CSS -> Disable Styles -> Disable All Styles. This is almost a visual "voice reader" simulation, except of course it doesn't say "image," "link," and so on. But if the page looks good this way (headings, organization, sensible alt text, etc.), it's probably close. If it doesn't make sense this way, then more thorough analysis is in order. (Try it on the inaccessible BAD Home page.)"{Sylvie}
- [closed] Tom writes: "I understand why they've had to include multiple systems (IE + FF), although FF can be used on any OS."
  Sylvie: It can be useful to evaluate with at least two browsers as they do not behave the same. For that reason, I think it is important to talk about IE and FF. {Sylvie}
- Here is a draft to add at the end of the current page if the group thinks it is useful and not beyond the scope of an "Easy Check" {Sharron June 4}

Comments on Linearize

Drafts:

[EOWG comment]
Do we want to include something like this at the end?
What are the benefits?
What are the cons?
If we do, what comments do you have on the draft text?
What should we call this section? (it's more than linearize, it turns off images & CSS as well)

comment {name, date}
I like the idea of this section - it adds something more to the checks than just yes/no
Benefits - gives a little experiential flavour of what some people experience
Cons - not about 'checking' per se, so could add confusion for readers
I'm not sure about the text that implies that screen reader users get linearised tables - if data tables are marked up correctly, then they make much more sense that what I see with a linearised table. {Andrew, 13 June}
I am ok with draft 3 which simplifies draft 2 a bit. Nevertheless, I think the words "some people" are written too many times. I suggest following rewording in mixing drafts 2 and 3:
While the other checks on this page focus on specific success criteria in WCAG 2.0, this check is more broad. It helps you understand how some people "see" the web page in other ways as usual. Frequently, web pages are designed with multiple columns and sections, colors, etc, that makes their content difficult to understand for users who are blind and listen to the page with a screen reader. Many users with low vision and others change the way the page is presented so they can read it; for example, change from multiple columns to one column, change the text size, and more. If you have no access to a screen reader or the knowledge of how to work with one, you may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles. This check gives you an idea of how people who are blind and others who get a linearized view experience the web page you are checking.
Note: BAD provides a clear example of how the plain text view reveals accessibility barriers. (It's also a bit funny, and we suggest you check it out, per the BAD instructions below.) {Sylvie, June 13}
I think this section could be helpful for people who need to have a quick look at a page without styles and images. this draft is not too long and clear. {Sylvie, June 6}

{Wayne June 14}

Safari Plain Text

Safari does not supply a linearize page option either natively or through an extension.

For the best approximation of a linear page do the following from the Develop Menue on the main menu bar. Select:

Develop > Disable Images
Develop > Disable Styles

For Keyboard access press

ctl+f2 > d > press down arrow until Delete Images
ctl+f2 > d > press down arrow until Delete Styles

If your Safari lacks a Develop menu go to Safari preferences, choose the Advanced Tab and on the last check box on the control select, "Show Developer Menu."

Linearize Page (Optional)

Not everyone has access to a screen reader or the knowledge of how to work with one. You may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles so that the reading order and text alternatives are exposed and can be evaluated.

What to do:

The checks below provide instructions with different browsers for how to:

Expose text alternatives by removing images
Reveal the reading order by turning off the associated style sheets
Examine the resulting page display for an approximation of a screen reader experience.

To linearize with IE WAT

Open the page you are checking in the IE browser
Using the toolbar, choose Images > Remove Images
Next choose CSS > Disable CSS

comment {name}
Shortcuts in WAT toolbar are:
With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok"..
{Sylvie, June 6}

To linearize with FF web developer toolbar

Open the page you are checking in the FF browser
Using the toolbar, choose Images > Disable Images
Next choose CSS > Disable Styles > Disable All Styles

comment {name}
In the French Web Developer version the keyboard shortcut to hide CSS is alt+shift+a, but I am not sure if it is the same in the English one. For disabling images, I only have the French version's shortcuts here. {Sylvie, June 6}

What to check for:

Read through the resulting display and notice the following:

Make sure that there is text in place of any meaningful images and that the text provides the same information as the original. (review alt text section above)
Verify that the reading order is logical, complete, and makes sense.

Comment: {Wayne Dick} The inclusion of the linearizatin is important to the easy checks. I liked Sharron's start, but it was not inclusive enough, nor did it motivate linerization sufficiently. Quite simply accessibility is not achievable without the ability to linearize content in a semantically faithful way. Sharron, I hope I expanded you piece to meet your approval

Linearize the Page for Experiential Learning (Optional)

When a page is converted form text to speech, to Braille, or to very large print, the author's two dimensional presentation format breaks down. Before a page can be converted to an appropriate medium it must be reduced to a one dimensional information stream. This process is called linearizing the page.

Not everyone has access to a screen reader, or powerful text customization tools required to experience linearized content as it is used, but a linearized presentation of content is easy to simulate using the tools we have introduced so far. This can give the fully sighted reader an understanding of the day to day experience of users with blindness or low vision.

Linearization does not focus on any one success criterion, instead it reveals how well a page is organized to support accessibility. Example: Read the linearized view of the inaccessible version in the BAD Demo. That will be fun, and it reveals a lot of what can go wrong.

The checks below provide instructions with different browsers for how to:

Unclutter the linear view and expose text alternatives by removing images
Reveal the reading order by turning off the associated style sheets,
Expose navigation support for a one dimensional content format, and
Reveal the resulting page display for an approximation of a screen reader / customized text experience.

To linearize with IE WAT

Open the page you are checking in the IE browser
Using the toolbar, choose Images > Remove Images
Next choose CSS > Disable CSS

Shortcuts in WAT toolbar are: With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok".. {Sylvie, June 6}

To linearize with FF web developer toolbar

Open the page you are checking in the FF browser
Using the toolbar, choose Images > Disable Images
Next choose CSS > Disable Styles > Disable All Styles

In the French Web Developer version the keyboard shortcut to hide CSS is alt+shift+a, but I am not sure if it is the same in the English one. For disabling images, I only have the French version's shortcuts here. {Sylvie, June 6}. This doesn't work in the English version {Wayne, June 11}

What to check for:

Read through the resulting display and notice the following:

Make sure that there is text in place of any meaningful images and that the text provides the same information as the original. (review alt text section above)
Verify that the reading order is logical, complete, and makes sense.
<new> Make sure that there are reasonable ways to skip around long lists of links and other boiler plate content that is repeated on every page in the site. </new>

Introduction

Introduction in WAI draft page

Status:

Complete, ready for detailed review.
no major edits since February

Comments:

comment {name, date}

Page title

Page title in WAI draft page

Status:

Complete, ready for detailed review.
OPEN: a couple things listed in "To be implemented" below

30 May edit: significantly edited the first part.
24 May edits: changed images.
21 March edit: changed "Best practice is for titles to be "front-loaded" with the important and unique identifying information first..."

Comments:

comment {name, 00 month}

Image text alternatives ("alt text")

alt text in WAI draft page

Status:

Complete, ready for detailed review.
only minor edits since February

Comments:

comment {name}

Headings

Headings in WAI draft page

Status:

Complete, ready for detailed review.
30 May edits: changed 'What to check for' from questions to statements to be consistent with other sections.
21 March edits: combined instructions under each tool

Comments:

comment {name}

Luminosity Contrast

Visual contrast in WAI draft page

Status:

Overall flow, instructions, text is complete and ready for review.
OPEN: Needs someone to fill in some details on using the tools. - Vicki will do it

10 May edit: changed heading from [Luminosity Contrast ("color contrast")] to [Contrast Ratio ("color contrast")]
22 March edit: changed heading to Luminosity Contrast ("color contrast")
21 March edits:
- changed heading to Visual contrast ("color contrast", luminosity contrast)
- tweaked wording a bit and added: This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminosity contrast".
7 March edit: moved the 3 options with pros & cons from under "To check contrast with IE WAT" up a level to apply to all.

Comments:

[closed] I think right above "Download the Color Contrast Analyzer" the heading needs to have the word "Windows" added so it changes to "To check contrast with any Windows browser." {Anna Belle}
reply: a mac version is available - http://www.paciellogroup.com/node/18?q=node/20#macdownload {Andrew, 15/March}
Questions: Is "you don't need to install it so should be able to do even in environments where you cannot install software." true for that TPG Windows & Mac versions as well? The current link goes to Vision Australia page with "Color Contrast Analyzer". The TPG version is called "Contrast Analyser" - which is better. Should we just point to that one?
Reply: The CA and CCA are the same - when installed, the CA2.2a from TPG is actually 'Colour Contrast Analyser version 2.2a'. Also, the TPG and the Vision Australia downloads are the same tool - it was originally developed at Vision Australia then Steve moved it to TPG when he moved - VA retain up-to-dates version on their site. I don't know if the Mac version needs to be 'installed' or not. {Andrew, 22/March}
[open action for Mac] Someone please check if "you don't need to install it so should be able to do even in environments where you cannot install software." is true for that TPG Windows & Mac versions?
I tried on a Mac and the link on the page (unlike Andrew's link) sends me to a download page that's for Windows not Mac. That's even when I'm on a Mac. Maybe have a second link for Mac?{Anna Belle. May 30}
The Windows one required me to be admin as well, so I just deleted this all together. {Shawn}

Zoom

Zoom in WAI draft page

Status:

Complete, ready for detailed review.

8 March edit: Added "If possible, you should check zoom text only." and moved "To check zoom text only" up.
7 March edits were mostly minor. Note new second sentence in first paragraph: "Some need to change other aspects of text display: font, space between lines, and more." This is important so that readers don't think simple zoom covers all user needs (like in the color section we mention the need for low luminosity).

Comments:

comment {name}

Keyboard access, content order, visual focus

Keyboard, etc. in WAI draft page

Status:

Complete, ready for detailed review.
14 May: significant edits.

Comments:

comment {name}

Illustrations of focus indication would be useful. Shall I send screen shots to the list or how to provide? {Sharron}
Send them to Shawn & she'll upload them :) {Shawn}

Forms, form labels, and error messages

Forms in WAI draft page

Status:

16 May: significant edits.
Note: more updates coming

Comments after 14 June

comment {name}

I thought we talked in one eowg conference about the term "drop-down list box". Is it really the right term or don't you call them drop-down lists? {Sylvie, 17 June}
- "drop-down list box" seems clearest. Is that OK? {Shawn, 17 June}
- I never heard that before but if it is the current term, it is ok. {Sylvie, 18 June}
"Check that the focus is at the error message."
Proposal for clearer guidance:
After you have submitted the form with errors, check that your browser brings you directly to the first error on the page. One best practice is to list all errors at the beginning of the form that contain an internal link leading directly to each error."{Sylvie, 17 June}
- Two questions with this:

How do people "Check that the focus is at the error message" or "check that your browser brings you directly to the first error on the page"? I think this is easy to check with a screen reader but maybe not visually?
Response from Sylvie on June 18: if you take the example of search engines like Google, when you open the home page your browser prompts you directly to the search field, and this even without a screen reader. I am right?
The next bullet says: "Generally it is best if the error messages are before the form, rather than after the form." Is saying "One best practice is to list all errors at the beginning of the form that contain an internal link leading directly to each error." too prescriptive? If not, how can we integrate it into the existing bullet?
{Shawn, 17 June}

I am not sure if it is too prescriptive. It is only an example of what can be done to help the users find the errors. {Sylvie, 18 June}

In the note for labels checks, clarify following sentence:
"Note: These instructions help you check if labels are marked up with 'label', 'for', and 'id'; they do not check if form controls are identified in other ways. Therefore, even if a form does not pass these checks, it might still meet WCAG 2.0 another way."
{Sylvie, 14 June}
- I added the sentence before in your blockquote. Can you say what is not clear? How me might clarify it? {Shawn, 17 June}
- I mean the sentence: "Therefore, even if a form does not pass these checks, it might still meet WCAG 2.0 another way." I am not sure that this "another way" is clear. {Sylvie, 18 June}
[closed ?] In Check labels with FF, I don't understand following note:
(There's not an easy way to check form control labels with the FF toolbar. The Form Labels favelet works with Firefox, yet it requires installation.)
What does this enable you to do? Why do you mention that it requires installation, as FF toolbar also requires installation. More explanations are needed here. {Sylvie, 14 June}
- OK, I added more explanation: "The Form Labels favelet works with Firefox and provides the same information as from IE WAT above." We mention it requires installation because in the beginning we say we only use to 2 tools that require installation, so this is an exception. {Shawn, 17 June}

Closed comments:

[closed.] I am not sure if it is linked to my screen reader, but I am not able to have the links work, such as the link to drop-down list box. {Sylvie, 17 June}
That's because the in-page links go to other sections that are now in the main document at /WAI/eval/ but not in this draft (at /WAI/EO/Drafts...) anymore. They should work when we move this section into the main document.
[fixed.] In the paragraph "Error handling", first sentence, there seem to be a typo:"Some single simple forms, such as a single search fields,"write "a single search field". {Sylvie, 17 June}

Comments after 10 June

Background: Forms e-mail 10 June. Given that easy checks can not tell you pass or fail for labels, and the liklihood of false failures, do we still want to include labels? See Criteria for what to include.
- I understand the arguments, but they are so common and so often badly done (i.e. inaccessible) that it would be a shame to drop them. Maybe we need a 'not-so-easy checks' page to follow on with :) {Andrew, 13/June}
  Anna Belle moaned when I mentioned that option. :) Remember that we added a section on things that are not included in the easy checks {Shawn, 13 June}
- I've been checking the method of clicking on the label to perform the check. I haven't found any false positives nor the opposite; and it seems to work on buttons, textarea, checkboxes, radio buttons, etc. {Howard, 14 June}
  It works when the label is implicit. Is this false pass? Explicit labels were required with WCAG 1.0 — although not exactly in WCAG 2.0. We should research this more. {Shawn}
  well, H65 says "Using the title attribute to identify form controls when the label element cannot be used" impying that the label ellemnt shouod be used whenever possible. Which is what most of us advise. {Andrew, 13/June}
Is there a way to check label markup with FF toolbar? If not, should we not have a FF section at all?
- As far as I can see, FF toolbar can only display/highlight forms fields without labels: Forms > Outline Form Fields Without Labels {Andrew, 13/June}
  Right. I've got that in the draft and note: "Some fields without labels will get a thin red border. (Note that this only works for some text fields and buttons, not for radio buttons, checkboxes, and drop-down boxes.) [@@ true? seems so with BAD anyway. also, i find it a bit hard to see the thin red border. With these limitations, is it worth including this step?]" {Shawn, 13 June}
- I don't fine the red outline that hard to see. Also, what about the Wave toolbar to check labels or the AIS toolbar (see http://html.cita.illinois.edu/nav/form/form-test-ais.php) Or are these types of toolbars too complicated for Easy Checks? {Howard, 14 June}
  We decided to limit the number of tools and I don't think we want to add AIS. Some people find WAVE difficult to use; however, we do use it in one other place. It also has the implicit label issue. We should research this more. Maybe WAVE is a good option here. {Shawn}

Comments before 10 June

[done] say explicti lables on radio buttons make the whole thing clickable! {Shawn, Paul}
[closed? added to current draft intro sentence with all issues] The prose version is a significant improvement over the bullet version. The former leads off with a clear introductory sentence and then proceeds with a nice overview of the issues, providing a rationale for the more detailed instructions that follow. The bullet version starts right off with specifics which is jarring and disorientating. {Howard, 6 June}

Other observations/feedback: {Howard, 6 June}
- [done. fixed] the link to the "preliminary" page is broken
- [EOWG open - heading for this section simply "Forms?" or more?]
  Title on current version is "Forms and Error Messages" but in this wiki it's "Forms, Form Labels, and Error Messages." I prefer the latter
  - Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? {Shawn 10 June}
- [closed. current draft has "Find forms on the page."] "Find Forms" header under "What to do" seems too open. Suggest: "Find the forms on the page" (too wordy?); or "Find form elements" (too technical?)
- [closed? current draft has bullets under the subheads] This section, being lengthier than the others, calls for additional indentation - under the brown headers, such as "What to do", "What to check for", etc. Too much lines up along one left margin. Some additional indentation would add readability. (Perhaps once images are added, this will help subdivide the section)
- [closed current draft covers it in keyboard section] Maybe the "submit button" section could be replaced with a statement such as:
  "Form data should not be submitted without user confirmation" (followed by more detailed instructions?)
- [closed? edited in current draft] I think error messages should be addressed in "to learn more about forms." Otherwise, this section is getting to lengthy and thus no longer an "easy check".
- @@As mentioned under "to do items," the group label is not sufficiently explained. Maybe have a link from "group label" where it can be further explained.

As discussed in EOWG's 31 May teleconference, I suggest changing the checks order as proposed below:
1. Labels
2. Instructions
3. Keyboard access and reading order
4. Submit buttons
5. Data input and error messages
{Sylvie June 4, 2013}

In section "error messages", we should give clear instructions on what to look for, avoiding asking for judgement.
- Check that there is guidance to help user understand and fix the error.
- The focus moves to the error message
- Error information is not located at the end of the form, but rather at the beginning.
- The user is not requested to fill in the whole form again, but only the error fields.
- If the error concerns a format, such as date, time, address, suggestions are made to enter the correct format.
- If a required field has been forgotten, that this field is indicated with colour and text such as "mandatory" or *.
{Sylvie June 4, 2013}
[EOWG discuss] Are these easy checks? I wonder if all of what's currently in the Forms section qualifies as easy checks? For example,
- Is "Instructions" too soft/unclear/nonspecific?
- Indicating required fields is a bit tricky. Do we say enough here? Or is it too complex for an easy check? ... oh, I see now that required is in the Instructions subsection and the Labels section.
- Is "Data input and error messages" too hard for an easy check?
Also: My preference would be *not to have any specific instructions* under "2. Keyboard access and reading order" but instead have just a point to the keyboard access section above (and make sure it clearly includes keyboard access issues for forms). If y'all disagree, we can talk about that in EOWG telecon.
Also: "4. Submit buttons" is already covered in the keyboard access section above. I don't think we want to repeat it. (also, most of these wouldn't have buttons labeled "submit", they'd be something like "go to Page")
Perhaps we want to re-focus this section to just Form Labels? {shawn}

Reconsider the "What to do" section. Remember we've positioned this Easy Checks as applying to ONE web page (so "Check through the web pages to look for examples of forms." is not relevant). Can you make that section more succinct? Do we even need it at all? (Maybe to point out that a search box is a form?) {Shawn}

BAD: Rather than having a link to BAD in the "To learn more about forms" section without any explanation of what to look for in BAD, perhaps it would be useful to have a section on using BAD to check forms issues -- for example, like this one for alt: <http://www.w3.org/WAI/EO/Drafts/eval/checks#bad-alt> ? {shawn}

[closed] Suggest changing:
Forms are used for interacting with websites and are common across the Web. They are used for activities such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations.
to:
Forms are used for SUBMITTING DATA TO websites and are common across the Web. They are used for OPERATIONS such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. {Howard 23 May}
Suggest changing:
Forms are made up of controls such as text entry fields, check boxes, radio buttons, drop-down boxes and finish with submit buttons.
to:
Forms CONSIST of data entry fields, including text fields, check boxes, radio buttons, drop-down boxes and controls, usually consisting of a submit button. {Howard 23 May}
Actually, I think the introduction should take a different approach — not to introduce forms per se, but to introduce some of the accessibility issues with forms — like the other sections do. {Shawn 24 May}

[closed] Suggest changing:
For longer or unusual forms, check for instructions.
to
For long or complex forms, check for instructions.

Suggest deleting:
Instructions are usually needed to explain how to fill out the form.{Vicki 24 May}

[closed] Suggest changing:
Are there instructions at appropriate places in the form (usually at the beginning and the start of discrete sections) that clearly explain how to fill out the form?
to
Are the instructions positioned appropriately (usually at the beginning of the form and/or at the start of specific sections)?
Do the instructions clearly explain how to fill out the form?

Suggest changing:
Are required fields explained in the instructions and clearly identified throughout the form?
to
Are the required (mandatory) fields explained in the instructions and clearly identified?
{Vicki 24 May}

SK/MC case study - Good to have forms, but new post form was not available for public view. Really need to have a developers toolbar or IE WAT or WAVE to test this easily. Developer could not access tools from his machine and I could not access the page from my machine! We looked at BAD in order to consider the principles, having an example really helps. {Suzette}

Multimedia (video, audio) alternatives

Multimedia in WAI draft page

Status:

Complete, ready for detailed review.

24 May minor edits.
21 March: significant edits.

Comments:

comment {name}
retested keyboard access to YouTube using NVDA in Firefox - results follow{Howard, 27 June}

with nvda in firefox
Once you have found or chosen a video in YouTube, use 'O' to find embedded object. Flash player announced as "embedded object, clickable"; (note: if you hear "no next embedded object," press shift+O. Found that either the 'O' or shift+O got me into the player unless I was in the browser menu area. If I pressed tab until I reached the labeled YouTube logo, I could then use the 'o' command reliably.)
Press tab to move through player controls which will show a border as each one receives focus
will hear "turn captions on" when reaching the cc button, Press space or enter to turn on captions. (Note: once turned on, captions cannot be shut off via the keyboard. You can tab and shift-tab to reach the other controls and cc button will be announced but you cannot access the "turn captions off" option via the keyboard.
Note: Can only do this with a screenreader. Otherwise, no feedback to indicate when you have accessed the player via the keyboard.

for other captioned sounds, suggest:

water dripping, applause, laughter, writing on blackboard, tires squealing, etc.

{Howard, 6 June}

accessing cc with keyboard:

with nvda in firefox
'O' to find embedded object. Flash player announced as "embedded object, clickable"; (note: took me some moving and tabbing around the page before 'o' worked to find embedded objects)
pressing the enter key brings you to player controls;
down-arrow will then take you to the closed captioning on/off control.

Note: Without the screenreader could not really tell where I was on the youtube page using the keyboard. Not sure if these instructions can be made clear or definitive enough to be useful.
helpful youtube keyboard shortcut page: http://support.google.com/youtube/bin/answer.py?hl=en&answer=189278

{Howard, 6 June}

[done] suggest changing
"Most video on the web that provides captions has "closed captions" that need to be turned on."
to:
"Most video on the web that provides captions has "closed captions" that can be turned on and off". {Howard - May 31}

Next Steps

Next Steps in WAI draft page

Status:

Complete ready for review - updated 4 June

Comments on Next Steps

comment {name, date}
maybe summarize other things that need to be checked that aren't covered on this page? {Shawn, 7 June}
Potential things to list:
- comment {name, date}

Contributors

Thanks to:

Those who participated in the F2F before CSUN in February: Andrew, Anna Belle, Helle, Jennifer, Shadi, Sharron, Shawn, Wayne
Those who edited in December and January: Suzette (forms, @@), Sharron (Intro, @@), Shawn (Intro, page titles, headings, alt text), Ian (zoom n text resize).
Those who commented in December and January: Sylvie, Wayne, Anna Belle, ...
Those who drafted checks 16-28 November:
- Sharron for drafting {list sections!}
- Suzette for drafting : Check usable with page zoomed and text enlarged, Check color contrast, Check color coding and shape coding, {?other sections}
- Wayne for drafting {list sections!}
Andrew & Shawn for editing the keyboard access & visual focus section in early Nov.
Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the f2f in Nov.
Sharron for help making all the early drafts and versions less confusing.
Wayne and Ian for sharing colleagues' related work.
Denis for edits to the old page content.

testing image: