Prelim Eval 2013-Nov-4

From Education & Outreach

Nav: EOWG wiki main page > Evaluation Pages
[Old Web Accessibility Preliminary Evaluation page] 


This is an old archive of the Easy Checks wiki page


To Do

Page titles

  • [closed] Find a keyboard way to display the full page title in IE 9 and later and chrome.
  • Chrome and some versions of IE do not have a title bar. In those browsers you can see the full page title by hovering over the tab [@@keyboard way to do this?], like this: [@@ need to redo this image with a browser that does not have a title bar]
    • I found this Chrome extension to display page title . It requires another download, so not sure if it would be useful. {Sharron 27 Oct}
    • I tried to use it but think it's a bit difficult and not sure it helps to find the page title. How does it work in Screen readers?{Helle 1. Nov.}
    • Chrome requires an extension to show the page title, I could not find any extensions better than the one Sharron found. {Paul}

Headings

  • [done] Learn more about headings - Delete the techniques? Elsewhere we just have links understanding success criteria. Would it be too much -- and beyond Easy Checks goal -- to list all the relevant techniques for each section?
    • Agree to delete the Techniques and just leave the SC reference here {Sharron, Oct 27}
  • Agree to delete techniques etc. as suggested {Helle 1. Nov.}

Contrast

  • Don't understand question: [@@ how to show where it is on the page]{Helle 1. Nov.}
    • Someone said there is a way to get from the table to where it is on the web page -- that is, from a row or cell in the table you can see where that is on the page -- but I don't know how to do that...
  • comment {name}

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."
    • Suggested revision: "To select a specific item within an element such as a drop-down list, tab to the targeted item so that it has focus, then press the Enter key or Space bar. Verify that the intended item was in fact selected." {Sharron 27 Oct}
    • Prefer Sharron's suggestion, "EOWG thoughts" is to short and not clear {Helle 1. Nov.}

Resize Text

  • [open] Zoom - keyboard shortcuts. Following up public comments I rechecked the content of text only and whole page zoom. In Mac Safari and Mac FF, when you use the View drop down and select text only zoom - it puts in a tick and then any increase/decrease impacts text only (using cmd with + or -). BUT in Windows FF, you can chose either page or text zoom from View menu. However, the keyboard short cuts are different for text an page zoom. Zoom page is the default ctrl + or - with ctrl zero for reset to default. Text only zoom is thus "control key AND shift key with + key all at the same time". I recommend we add this as an extra line to step 2.
    I don't use IE much and I don't use a mouse - but does anyone know if it still does zoom using the mouse wheel? Also is this only page zoom? (For reference I am on v22 for both Mac FF and Windows FF){Suzette}


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. (How to do it with nvda from Howard -- but we want more generic instructions, e.g,. sighted keyboard users.)
  • [EOWG thoughts?] "If there are captions, transcripts are not usually required; however providing transcripts in addition to captions has many benefits — both to people with disabilities and to website owners. [EOWG: OK to say??]" Should we point to Benefits?
    • I think this is definitely OK to say, and yes, it should point to benefits. In fact the benefits are even broader than what we claim here. Besides PWD and website owners, captions support literacy for all readers. Captions for Literacy provides links to research if we want to get that detailed.{Sharron 27 Oct}
  • [EOWG thoughts?] "Check that transcripts include all audio information, including dialogue with the speakers identified, and all important sound [repeat examples above or not?]."
  • comment {name}

Forms and errors

(Other open issues are being discussed in the Forms section below.)

  • [EOWG thoughts] In BAD, it seems that the focus does not go to the error messages. Shall we still include BAD for checking errors? We can submit a change request for BAD, but it will likely be a while before it gets implemented.
  • [OPEN action] suggest edit for: "Data tables will not make sense when linearized -- that's OK -- screen readers have functionality to make them usable (when the table is marked up correctly)."
  • [EOWG thoughts] suggest edit for: "Check that the information makes sense, for example, [@@ reading order]."
  • [New item] Added draft text for "Check labels if you are comfortable looking at code" in Forms section, below
  • comment {name}

Plain text view / Linearize

  • [EOWG thoughts] [ 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. @@ need to be more specific on this one - how do they check that? what specifically are they looking for? or is this not a priority and we should leave it out?]
  • [EOWG thoughts] To practice checking plain text view with BAD section: Do we want to point out other things?
  • comment {name}

Next Steps

  • comment {name}

Throughout:

  • EOWG folks: search for "EOWG" below (which is highlighted yellow) and add your comments.
  • [wait until illustration strategy is decided] Check img alts - some might have @@
  • [wait until illustration strategy is decided] Decide if we want more images for the steps. Search for [image].
  • [done for now] 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}
  • comment {name}

Misc:

  • comment {name}

Overall

  • When I followed the Page Title link from the top of the easy check page, I was a little confused by the icon next to link. I thought it might be some kind of a drop-down. I realized that it was just part of an anchor link when I followed the "markup" link inside the Page Title description and was jumped to the "Back Ground" section.{Jan}

Intro

  • [question for Jan :-] Under "Easy Checks, A First Review of Accessibility," possibly change the third paragraph to read, "This page provides checks for specific aspects of a web page and suggestions for Next Steps(link)." (Then remove the phrase below the specific aspects anchors that refers to next steps). {Jan}
    • Can you say why? I'm missing the rationale for moving the link to Next Steps up before the links to the main content? {shawn}

Using these Easy Checks

  • [closed?] Maybe move the expand/collapse buttons that are directly above this heading to be underneath this heading. {Jan}
    • Those expand/collapse buttons apply to the entire page, not just the "Using these Easy Checks" section. Do we need to say explain that better? We can check during usability testing... {Shawn}

Background

  • [EOWG discuss] I think the statement, "screen readers are software that reads aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities" might be misleading. People with "reading disabilities" typically use "text readers," which are different from "screen readers." Screen readers not only read aloud the information on a web page, they also allow for mouseless navigation, which I think is an important distinction. Maybe consider changing the statement to something like, "screen readers are software that reads aloud the information in a web page and provide for navigation without a mouse. They are used by people who are blind or visually impaired." I just think that there needs to be a distinction between screen readers and text readers and who the targeted populations are. If the group agrees with this suggestion, then we would need to change the definition for screen readers under Diversity in Web Use as well @ http://www.w3.org/WAI/intro/people-use-web/browsing#sr {Jan}
    • comment {name}

Page Title

  • comment {name}


old page title notes

Under "What to do", "In those browsers you can see the full page title by hovering over the tab [@@keyboard way to do this?],". You can access the page title by pressing Control+D to add a bookmark (you can copy it or read it and then just press cancel). Chrome has a "View page info" option in the context menu (I'm using Windows here) but unlike Fireofx it doesn't display the page title.

In my installation of Internet Explorer 9, the title is displayed. However, if it isn't, you can press the context menu key or shift+F10 and select "Properties", which shows the title in the properties sheet.

{Alan via e-mail}

  • With the control-D option, you can also press "escape" to cancel the add bookmark after you view the full title. A helpful keyboard shortcut site is: http://www.shortcutworld.com/ {Jan}

Does Shift+F10, Properties bring up the Properties dialog box with the page title at the top in different versions of IE?

Comments:

  • IE8 on Windows Vista - yes (but the page title is shown anyway)
  • Tested in IE9 with Win7 Professional = works but you need to reach the Properties modal first {dboudreau, 20130809}.
  • In IE10.0.9200.16721 with Win7 Enterprise, it brings up a menu. Properties is the last item in the menu. When you select Properties, it brings up the dialog box with the page title at the top. {Jan}
  • [done] Grammar: For the phrase, "shown in browsers tabs when there are multiple web pages open," either use the singular "browser," or make "browsers" possessive: browsers' {Jan}

Resize Text

recent internal version

  • comment {name}

Previous Comments:

  • [EOWG decided to leave "text-only zoom" since that is the most common terms used in the browsers UIs. and to front-load it as "text-only zoom" (rather than zoom text only) to help differentiate with from page zoom. and list the 3 ways to resize text in bullets so they are more clear. see 1 Nov minutes for discussion]
    As a general rule, I would avoid talking about text zoom and talk about text resize instead. Keep the word zoom for browser zoom, which is a totally different thing. Comparing text zoom and browser zoom is not distinctive enough in most people’s minds. {dboudreau Oct 30th}
    3rd paragraph. Instead of saying “when it is changed through text-only zoom or text settings…”, I think we should say “when it is changed through text-only resize or text settings…” {dboudreau Oct 30th}
    • afaik:
      In Firefox it is: View > Zoom > Zoom Text Only. {keyboard - [alt-V,Z,T]}
      In Safari, it is View > Zoom Text Only.
      In IE it is View > Text Size > [Largest...] {keyboard - [alt-V,x,g]}
      In Chrome & Opera zoom text only is not available.
      Shawn to add keystrokes to page {Shawn - correct, Andrew}
  • [closed (deleted sentence all together] Instead of saying “Web pages should be designed to work when users change text size.”, I think we should say “Web pages should be designed to remain functional when users change text size.” {dboudreau Oct 30th}
    • humm "remain functional" seems kinda jargony. other ideas? <{Shawn}
    • readable or easy to read {Sharron Nov 1}
  • [done - changed section to "Horizontal scrolling is not required to read sentences or "blocks of text". It is best practice that when text size is increased, all the text in a sentence is visible. It is acceptable to have to scroll horizontally to get to different sections of a page." ]
    In what to check for, last bullet, following sentence is long and difficult to understand:

    "It is best practice that when text size is increased, lines of text do not go outside of the visible window and require people to scroll horizontally to read a line of text."

    {Sylvie, 28 October}
  • [done] In "What to check for", third bullet: "Text, images, and other content doesn't overlap." Write: "Text, images, and other content do not overlap." as it refers to text, images and other content? {Sylvie, 28 October}
  • [fixed] Typo: second paragraph Preferenes), instead of Preferences. {Sylvie 28 October}
  • [done? tried simplifying the text and adding the images. "When text is increased, sometimes part of the sentences are not visible and users have to scroll horizontally to read a sentence, as shown in the third example below. " How does that work?]
    This sentence may have unfamiliar concepts - "wrap" and "horizontal scrolling." "When text is increased, sometimes sentences do not "wrap" and so users have to scroll horizontally to read a sentence. Most people cannot effectively read text that requires horizontal scrolling, and some disabilities make this impossible."
    • Suggested revision (may be too much information, but something like this to avoid those terms):
      Text character size enlargement causes the length of the line of text to increase as well. It is important to confirm that the line of text is also rearranged within the current screen size and is not pushed off the screen. When text is pushed off screen, it becomes necessary to use the scroll bar to move sideways back and forth through the text. Studies show that it is not possible to read effectively in that situation and so it must be avoided. {Sharron 27 Oct}
  • [fixed] The second paragraph (1st sentence) is missing a period at the end. {dboudreau Oct 30th}
  • [done] 3rd paragraph. Instead of saying “When pages are not designed well, they can be unusable…” I would prefer “When pages are not designed properly, they can be unusable…” {dboudreau Oct 30th}
  • [closed?] 3rd paragraph. To avoid repetition, instead of saying “or text disappears.”, I would prefer “or text is lost.” {dboudreau Oct 30th}
    • I prefer to leave it more simple. repetition is OK here, I think -- better than using different words for the same thing. (I though about changing the first "disappears" e.g., "the space between lines disappears" -> "lines get scrunched together" but that may be hard to translate :-){shawn}
  • [done] Figure caption: Avoid the use of the word “zoom”. In this particular case, we care talking about text resizing, not browser zoom. {dboudreau Oct 30th}

Keyboard

7 August changes

Comments after Sept 2013:

  • [done] RE:

    All functionality by keyboard: Check that you can do everything with the keyboard; that is, you don't need the mouse to get to actions, options, visible changes, and other functionality. (A common problem is that some things are available only with mouse hover, and are not available with keyboard focus.)

    Yes, this is getting to the issue. Phrasing still seems a bit awkward however. Perhaps "you don't need the mouse to activate or trigger (instead of get to). And can we find another, more specific word than "things," as in "some things are available...?" Maybe "A common problem is that events and information are dependent on mouse hover and are not made available by keyboard focus - and should be." {Sharron, 26 Oct}

Previous Comments:

  • [added placeholder for illustration] 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}
  • [done] [last sentence of the introduction] The sentence "Keyboard focus should be visible and logical through the page elements" is not as understandable as it could be. The words "visible and logical" are different concepts. It might work better expanding a little and keeping the user's point of view used in the rest of the paragraph. For example, "As a user moves the focus from one page element to the next, she/he needs to be able to see which one currently has focus. The order needs to match the way the user reads the content." {Alan via e-mail}
    proposal: just drop this sentence all together. The details of what to check and how to check it are below and don't need to be said here.
    Maybe try: ""Keyboard focus should be visible and should follow a logical path through the page elements" or similar to separate the ideas {Andrew}
  • [done - deleted "indicator" so it reads: "Check that the focus is clearly visible as you tab through the elements..."] Under "Visual focus," "the focus indicator" suggests some kind of device, rather than simply a change in appearance. Maybe it would be clearer as "the focus is clearly indicated." {Alan via e-mail}
    [changed "for example: to "e.g.,". didn't start new sentence because it would have given the example too much weight] Maybe start a new sentence in "has focus, for example...", like "has focus. For example, ..." {Alan via e-mail}
  • [done - added "without triggering an action." (didn't bold "all")] n the "Drop-down lists and image links" section, maybe add emphasis to "all" in "move through **all** the options." Perhaps append "without triggering an action." {Alan via e-mail}

Forms, form labels, and error messages

Forms in WAI draft page

DRAFT of addition to Forms Section

If you have a basic familiarity with HTML, you can drill down on how the form is coded. While HTML allows both explicit and implicit form labels, some assistive technologies do not correctly handle implicit labels. One of the most reliable techniques for making forms accessible to assistive technology is therefore to use the label element to explicitly associate the form control with the label. This ensures that however the user comes to the form control, its purpose will be clear. If you are comfortable looking at the code, the following will help you identify accessibility features.

What to do:

  • Open the source code of the page you are testing and find the section that contains the form.

What to look for:

  • Verify that a label is attached to the form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control. The id attribute may have the same value as the name attribute, but both must be provided, and the id must be unique in the Web page.

{Sharron, 3 Sept 2013}

Comments after 14 June

  • comment {name}
  • Completing forms: I think some illustrations will be useful to the novice trying to understand forms using the WAT results. I am not sure how the proposed image in step 2 will differ from the image in step 3. In either case showing a present and absent label for or id will be sufficient. For step 5 however, I cannot see how WAT helps - surely you have to look at the code view to see if the asterisk is included or excluded - or am I missing something? Would an image help? {Suzette}
  • Update to WAT: Many many thanks are due to both Steve Faulkner and Jim Thatcher for resolving some issues with form checking using WAT. Newest version of WAT is currently 2013-07-19 and not 2013-06-13 as stated in Easychecks introduction. {Suzette}


Downloaded new version of WAT - it is clearer that something is wrong than in previous version - many things are labelled now as input errors and also select errors and container errors - which Easychecks don't mention. Some specific fields picked up as lacking 'label for'. Is there a simple explanation for input and select errors? WAVE was easier to understand with its red and green luggage labels but there is a lot of other issues identified too. FF has a feature on Forms/ outline form fields without labels - the outline is a bit too subtle and easy to miss! On the other hand, if the form passed most success criteria I guess the whole thing would be much simpler! Is it sufficient that the novice tester can just say that this form needs further investigation?)

  • [EOWG review] "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:
  1. 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?
    Response from Shawn on 25 June: Yes, but how can the the person doing the check check that? Visually, if it is a text box, there is a cursor. How check non-visually? What if it's a control other than a text box? Or just a plain text message? How check that the focus is there?
  2. 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}
  • [EOWG review] 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}
    • [EOWG]: Do we want to be more specific? Or how else can we be clear without being too techy and detailed?
    • Would it be any clearer if "be WCAG another way" were changed to "meet WCAG in another way"? {Bim, 28 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:

  • [done. changed to drop-down lists] 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}
  • [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}

Earlier comments still open 18 June

  • [EOWG open - heading for this section simply "Forms?" or more?]
    • Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? {Shawn 10 June}
    • 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 {Howard, 6 June}

Linearize

  • comment {name, date}

[EOWG open]What to call this section?

(Keep in mind how it fits with the other items in the contents list.)

Brainstorms:

  • Plain Text View
  • Linearize the Page for Experiential Learning
  • Basic Display
  • Bare Bones Display
  • How some people "see" the web page
  • Information Organization
  • Different Presentation
  • ...

Comments:

  • I think plain text is a misleading term. It makes me think of the <pre> element. Very fixed and very rigid. Linearized text, is marked up HTML. There are links, headings, paragraphs everything but style, and regrettably data tables. Actually it is styled with the default HTML style. Links are blue, headings are big and lists are lists.
    Linearizatized text is very structured markup in a different format. If linearize is to geeky how about "reading order" --convert the page to reading order.
    For me plain text has a very bad connotation. People used to give ASCII page equivalents that were rarely equivalent. These alternatives were referred to as "plain text" alternatives.
    {Wayne, 17 June}
  • It's more than linearize or reading order, it turns off images & CSS as well. {Shawn}
  • I think "Linearize" has a foundation that can be explained and is traditional. But it could also be something like, "undress the page", or "stripping the page".{Emmanuelle, 18 June}
  • I agree with Wayne about the bad roof of plain text. I am afraid people think that making a page accessible is providing a text version without images and anythhing else. I like Emmanuelle's "undress the page" (I mean the idea in it). From the proposals above I would prefer "different view", or what about "alternate view or presentation?"? {Sylvie, 20 June}
  • I find the current draft of this section somewhat confusing - sometimes "linearize" is used, sometime "plain text". The difference between the 2 are not clear, at least not spelled out. I found the diagrams confusing because there's no explanation of how you render in 1 column versus "page linearized with styles off." I'm a little concerned with the term linearized - it's not a term, I believe, that is used in any other tool such as Wave or Web Dev'l Toolbar, etc. Perhaps there should be only one example (since this is easy checks) - a page with styles turned off. Explain this is used to hear how a screenreader will render the page. {Howard, 27 June}
  • How about "Text view" or "Reading order"? {Bim, 28 June}
  • Among the suggestions above, I prefer:
    • How some people "see" the web page
    • Information Organization
    • Or Bim's suggested "reading order".
    {Sylvie, 28 June}
  • I also like the idea behind "undress the page". What about "simplify the page" or "basics of the page" or "See the page framework" or similar {Andrew, 28 June}
  • comment {name, date}

Next Steps

  • 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: search-icon.png

Internal Notes

Illustrations

Note:

  • To see all illustrations, make sure to "expand all sections" because some of the illustrations are in collapsed sections. (however, keep in mind that most of the images will be collapsed by default)
  • Make sure to evaluate the images in context, that is, read the text around it and imagine you are a user.

Questions: How is the current use of images for illustrations throughout the draft? Too much? Not enough? Mostly helpful? Too cluttering? Feel free to comment in general, and on specific images.

  • comment {name}
  • From 24 May teleconference:
    • Generally the conceptual images are useful for contrast and zoom; simply the page title images {done 24 May}.
    • Mixed perspectives on the images showing menu items and such. For some people they are just clutter, the word instructions are clear enough. For other people, the images really help.
    • For now:
      • Include images showing menu items and such judiciously — if in doubt, do not include an image.
      • Crop or gray out all unnecessary clutter in images. (for example, page-title-image has the content of the web page grayed out.)

Strategy:

I'd like to discuss strategy for illustrations. {Anna Belle, June 9} Here are questions to consider:

  • Do we want to use captions? Always? Sometimes? If sometimes, then what distinguishes when they are needed?
    • I think it is visually simplier without captions. The images are all illustrations of specific points and the images are right after the points, then I don't think they need captions. {Shawn, 12 June} Agree {Andrew, 13 June}
  • If we use captions, then how? E.g. do we give a 10 pixel padding with a border that encloses both image and captions?
  • Do we have images embedded in the text flow or do we separate them out (e.g. float to right)?
    • I suggest embedded in the text flow. {Shawn, 12 June} Agree {Andrew, 13 June}
  • In some images do we want to use embedded explanatory text and arrows? This may be necessary if we aren't using captions. And even if we do use captions, for some concepts it may illustrate the point more clearly.
    • I suggest keep them simple -- both for the users reading the page and for us developing the images. I think it would be best to crop and gray out an irrelevant information in the images, and not have to use arrows. Also, if the images are embedded and they are illustrating the text right above them, then they shouldn't need explanatory text. {Shawn, 12 June}
  • What is the maximum width for an image?
    • We previously decided to make most images 700px wide. We can revisit that decision. {Shawn, 12 June}
  • If width is narrow (e.g. 350 pixels), some images will need to be shrunk to a size where detail may be lost. Is that okay? Or do we want to offer a link to a larger version of the image in such cases?
    • I vote let's try to make the images useable in the page, and not add the complexity of linking to a larger image. {Shawn, 12 June}
  • Do we want to number illustrations? Thus in the text we could say, "See Figure 3" multiple times if Figure 3 is relevant multiple times.
    • If we were referring to a single image multiple times, then we would need to do something like this. However, I think we don't refer to an image more than once. Also, currently the images are embedded in the text right after what they illustrate. Therefore, I think it would add unnecessary complexity (both for users and for us ;-) to number the illustrations. {Shawn, 12 June} Agree {Andrew, 13 June}
  • Do we want to incorporate all illustrations into the expand sections button? Or perhaps have a separate "See illustrations" button? (I dislike both of these ideas, by the way.)
    • Currently there are 3 types of images:
      1. Illustrate the concept (e.g., page titles, contrast, zoom).
      2. Illustrate the toolbar things to click.
      3. Illustrate the results from the tool, e.g., alt text next to images.
      Currently the concept images (1) are always shown, and the toolbar images (2 & 3) are shown only when that specific checks step is expanded. I think this works well. [Agree {Andrew, 13 June}]
      For the checks steps, we could have the illustrations not visible by default and a button to show illustrations. That might be best for usability; however, I don't think it's a high enough priority for our time. We do not currently have such functionality developed so it would be a new thing to do. {Shawn, 12 June} [Agree - and we don't need more delays in releasing {Andrew, 13 June}]
      To see how it might work, I put Images illustrating linearized and changed display (click to show images)
  • Do we want to limit illustrations to one per concept? If the concept is tricky to illustrate (e.g. how to see titles) do we want to offer the option of clicking through to more illustrations?
    • I don't think we want the complexity (for the users or for us) of adding the option to get more illusrations on a different page. Right now we have the following concept images:
      • Page titles - 1. shows page title in title bar and cut off in tabs. 2. shows how to get the title from the tab when there is not a title bar. [@@ we need to redo this image with a browser that does not have a title bar :-]
      • Contrast - several images that show different color combinations that are mentioned in the text.
      • Zoom - 2 that show a page not zoomed and zoomed.
      I don't think it makes sense to put these one a separate page. {Shawn, 12 June}
  • Do we want to standardize the format to the image? JPG? SVG? PNG?
    • I think png {Shawn, 12 June}
  • Would it be helpful to specifically state the goal for each illustration in the wiki? E.g. with titles, is it to show people how to see the title at the top of a browser (whether embedded in a tab or not)?
    • Yes. Please do! ;-) {Shawn, 12 June}
  • What should be the alt (&/or title) for illustrations in different cases, e.g., if the images are sufficiently described in the text, then null? {Shawn, 12 June}
    • For the Page Title images: Let me change the suggestion to indicating this information with a title attribute - the images look different from what I see on my setup, so hovering would show what browser & version was being illustrated {Andrew, 15/March}

Recommendations for Illustrations:

Version 5

Examples of multiple image with long caption under zoom, plus single image, and another double image.

Current questions:

  1. Does this zoom well?
  2. Does the width shrink well? (This is aside from the figure container overhang on the right in the multiple image example at decreased widths.)
  3. In other words, is this a good base for tackling the next issues?
  4. Anything else about version 5?

(Next step: Get rid of the style in the HTML.)

CSS: 

div.figure {
  max-width: 100%;
  margin: 1em 0;
  padding: 10px;
  border: 1px solid #aaa;
  background: #fff;
}
div.figure img {
  border: 1px solid #888;
  max-width: 100%;
  height:auto;
}
   /*
   div.figure.multimg {padding: 10px 5px;}
   div.multimg img {margin: 0 5px;}
   */
.figcaption {
  margin: 7px 0 0 0;
  font-size: 85%;
  color: #444;
  line-height:115%
}

HTML: 

<!-- width is the width of the image(s) + for multiple images, 11px for in between images (to keep them from stacking) -->

<div class="figure" style="width:@@px;"><img.../> <img.../>
   <div class="figcaption">Figure:....</div>
   </div>
Version 5 Comments
  • ... {name}
  • in CSS:
    div.figure... background: #fff;
     Why have a white background? This makes the figure stand out even more from the text, which I think it not s good. {shawn}
  • the CSS from ABL &/or Wayne included:
    div.figure.multimg {padding: 10px 5px;}
    div.multimg img {margin: 0 5px;}
    I don't see the reason for these. {shawn}
  • div.multimg img {margin: 0 5px;}
    That's to give horizontal space of 10px between multiple images; in combo with the "div.figure.multimg {padding: 10px 5px;}" instead of "padding 10px;" it gives same border spacing as single images. I wonder if it wouldn't be good to do the same with vertical space for then they stack? {Anna Belle}


Version 2, 5 August 2013

Phase I

  1. Visually separate illustrations from the text flow by using a border and 10 pixel padding around them.
  2. Do not float illustrations that are intrinsic to the text.
  3. Use captions as a general rule.
  4. Gray out irrelevant information in the images, and avoid using arrows if possible.
  5. The maximum width is 700 pixels. Use CSS of max-width 100% and height auto so images shrink in narrower windows.
  6. Illustrations and their captions will be left-aligned -- not centered or right/left justified.
  7. Use PNG for the format.
  8. Specifically state the goal for each illustration in the wiki. This will help select the best illustration.
  9. The main text, not the captions, is used to convey the important information.
  10. Alt text should (1) briefly explain what is being illustrated and (2) reflect the browser (including the version) and operating system used for browser illustrations.
  11. In preparation for HTML5, embed illustrations in a div element with a class of "figure" and captions in a div with a class of "figcaption".

Phase II

  1. Convert to HTML5 so we can use <figure> and <figcaption> elements for illustrations.
  2. Add a widget to toggle illustrations on and off.



HTML: 

<div class="figure" style="width:622px;"> <!--width of images + 20px for padding -->
  <img src="contrast-b-on-w.png" width="301" height="127" alt="black text on white background" />
  <img src="contrast-yellow.png" width="301" height="127" alt="yellow text on black background" />
  <div class="figcaption">Figure: High contrast examples.</div>
</div><!--.figure-->

CSS: 

div.figure {
	max-width: 100%;
	margin: 1em 0;
	border: 1px solid #aaa;
	padding: 10px;
	background: #fff;
	text-align: center;
}
div.figure img {
	border: 1px solid #888;
	max-width: 100%;
	height:auto;
}
.figcaption {
	margin: .7em 0 0 2px;
	font-size: 85%;
	color: #444;
	text-align: left;
}

Comments on Version 2

  • We should think about the overall approach to the main text, captions, alt, and title — to make sure we're not unnecessarily duplicating information, esp. for screen reader users. I think we run the risk of having unnecessarily verbose captions that add visual clutter — for example, they don't need to describe the visual: people who can see, see it - and people who can't, get it from the alt. What is the goal of the captions? {Shawn}
  • I think the captions serve an important purpose. I agree they shouldn't be verbose. Using the luminosity contrast illustrations as examples, captions: immediately inform the reader what the illustrations signify before reading the text; it clarifies what the text refers to. It can take a few scans between the illustrations and the surrounding text to figure out exactly what graphics are referred to by what text. Captions avoid or help to eliminate this step. {Howard, 15 August}
  • Not sure why the captions should be left aligned and not centered. What's the convention? (I think it's centered captions). Also, why no arrows or circles to emphasize the key portion of the illustration?{Howard, 15 August}
  • 1) Centred text is hard for some people with reading difficulties to deal with as they have difficulty finding the start of the line (see also the advisory technique at Guideline 3.1); 2) I think arrows or circles would be useful in some illustration i.e. judicious use{Andrew, 23/Aug}
  • comment {name}

OLD Version 1, Andrew and Anna Belle, 6/27/13

Phase I

  1. Visually separate illustrations from the text flow by putting border and 10 pixel padding around them.
  2. Do not float illustrations. Width issues and where they fall relative to the text are too complicated.
  3. Use captions as a general rule. Illustrations including captions within a border are visually simpler because the reason for their inclusion is explained rather than having to be deduced.
  4. Gray out irrelevant information in the images, and avoid using arrows if possible.
  5. The maximum width is 600 pixels.
  6. Illustrations will not centered, not right/left justified.
  7. Use PNG for the format.
  8. Specifically state the goal for each illustration in the wiki. This will help select the best illustration.
  9. Alt text should (1) briefly explain what is being illustrated and (2) reflect the browser (including the version) and operating system used for browser illustrations.
  10. Aside: We might consider embedding illustrations in a div element with a class of "figure" in preparation for HTML5. If we do this then the captions can go in a span with a class of "figcaption."

Phase II

  1. Convert to HTML5 so we can use <figure> and <figcaption> elements for illustrations.
  2. Add a widget to toggle illustrations on and off.

Illustration Goals

Plain text view:

  • Visually illustrate the concept of linearize
  • Simple example of how a layout can linearize in different order
  • Show what they can expect when they follow the steps
  • Show how people with low vision might change the display, to help show it's not just screen readers

Usability Testing

Things to test with users

  • Expand/Collapse: test to see if the "+/-" icons convey this feature
    • might want to consider putting text such as "expand/collapse" in addition to the "+/-" icons
  • Meaning of terms such as "accessibility," "page title"
    • Do users understand the term "accessibility"
      • We assume that by the time users access this page they understand the term "usability." Perhaps this needs to be reconsidered.
    • Do users understand what we mean by "page title" or do we need to explain further
  • Resize Text - especially check if they understand the horizontal scrolling bits

Case study notes

See SK/MC Case Study Notes in the 30 May 2013 snapshot

Consider for Later

  • The text says: "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? {Shawn}

previous versions, etc.

Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Prelim_Eval_2013-Nov-4&oldid=7146"