Prelim Eval 2013-Dec-13

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


Easy Checks - A First Look at Web Accessibility

Related pages:


Completion Plan

  1. open issues
    • everyone comment on all open issues below marked with "[EOWG..." by Wed 13 Nov
    • Discuss open issues in EOWG telecon on Fri 15 Nov
    • [done] Shawn update Forms section based on comments
  2. fresh perspective review
    • [done] Anthony & Jan review & comment on all sections — except Forms — by Wed 13 Nov
    • Discuss comments in EOWG telecon on Fri 15 Nov
  3. illustrations
    • Anna Belle... :-)
  4. usability testing
    • @@
  5. publication approval
    • @@

To Do Throughout:

  • EOWG folks: search for "EOWG" below 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}

Overall

  • comment {name}
  • [done] 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}
  • [done] This is off-topic, but as I was looking at this I noticed something else that seems worth a double-check. Specifically when I went to look at the Resize section at http://www.w3.org/WAI/eval/preliminary#resize (which appears to have replaced http://www.w3.org/WAI/eval/preliminary#zoom), I was distracted by the page "bouncing." It turns out in at least Chrome on Mac (and I bet other browsers) on hover over things like "To check contrast with IE WAT" (that is h4 .f_panelHead) it adds a solid border-bottom, when there isn't a border-bottom in non-hover state. Maybe add a solid border of background color for default to stop this jiggle?{Anna Belle 8 Nov}
    +1 on Anna Belle's comment on the jiggle. {Jan}
  • [closed] I really like all of the keyboard shortcuts that are listed throughout the Easy Checks for the Web Accessibility Toolbar. Is there a place on the W3C site where these kinds of keyboard equivalents can be accessed in one document or on one page? I know that the W3C doesn't endorse any one tool, but it might be helpful to new users to have access to a list of keyboard equivalents somewhere ... just a thought {Jan}
    Outside our scope. Let's encourage the tools to do it. {Shawn & EOWG}
  • [done :-] Newbie Praise of Previous Work: I really like the way the easy checks are formatted. They are consistent in terms of how you check in various browsers, etc. Once you have been through one section, the pattern is repeated in other sections, making it more usable and easy to find what you need. Nice job! {Jan}

Intro

  • comment {name}
  • [done] 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}
    • ''[response to Shawn :-] I thought about moving the Next Steps up because I thought that it was visually lost after the anchor links and seemed disconnected to the flow of content. It just seemed to me that the information about "Next Steps" flowed better as a part of the introduction sentence instead of being on its own after the anchor link content. {Jan}

Using these Easy Checks

  • [closed - explanation added] 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

  • [done] 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}
    • +1 for ths change to both places, since it is a more accurate functional distinction that has impact for different disabilities. I also appreciate the fact that it makes the relation clear to mouse-less navigation. {Sharron}
    • I'm not so certain that this distinction should be made. Perhaps it's a regional difference, but in UK screen readers are frequently used by people with reading difficulties, and the mousless navigation is more to do with the functioning of the screen reader, rather than of the visual ability of the user. {Bim}
    • I think I like Jan's suggestion, but am doing a local (Australian) check before I confirm {Andrew - 15 Nov}
    • I think this distinction is valid, but will be lost on someone who is performing an "easy check." Let's not get lost in minutiae. {Paul 11/21}
    • I was asked to rework the statement so that disabilities are not mentioned: "Screen readers are software that reads aloud the information in a web page and allow users to navigate without using a mouse."{Jan}
    • DECISION: change to " screen readers are software that reads aloud the information in a web page and enable keyboard navigation. They are used by people who are blind." {EOWG 29 Nov}

Page Title

  • comment {name}
  • [done - tweaked the section so the easiest option -- to just look at it with a browser that displays it automatically -- is first, then the mouse hover is next ~slh] I think its better to give the easy option as the 1st point for the user. 4th option is the easiest: "With your mouse, hover over the browser tab to see the full page title, like this:" {Anthony}

Image alts

  • comment {name}
  • [Anthony: are you OK with below?] Under Tips, in 5th point its better to mention about html longdesc element. We can write something like "......, and then the detailed description of the information should be provided elsewhere using html attribute "longdesc" [1]." {Anthony}
    • Maybe that's too technical for this document. How about: "If the image has complex information — such as charts or graphs — the image should have a short alt text, and then the detailed description of the information should be provided elsewhere (for example, in a data table)." {Shawn}
  • [done] Under "What's not needed in alt text:", 2nd point describes an example alt text for an diagram. Its confusing why its not needed? {Anthony}
    • I tweaked the intro to the section to be: "What is not needed in the alt text:" and changed the order of the bullets so as to avoid the misreading "when alt text is not needed". {Shawn}
  • [done] Under "Alt text checks", "There are three options for checks listed below." is not clear. Can we re-word it like, "There are three options to check alt text as below" {Anthony}
    • Changed to "There are three options to check alt text listed below." {Shawn}

Headings

  • comment {name}

Contrast

  • comment {name}
  • [Jan - are you OK with edit below?] I would recommend that we try to avoid giving examples of types of disabilities because people who have limited experience working with people with disabilities may tend to apply statements we make to "all" people who have that type of disability. For example, the following statement is currently in the Easy Checks under Contrast Settings: "While some people need high contrast, for others — including people with some types of reading disabilities such as dyslexia — bright colors (high luminance) are not readable. They need low luminance." I would recommend that we remove the phrase "such as dyslexia" so that people won't think that "all" people with dyslexia need low luminance. {Jan}
    • I think it's good to provide examples to make it real. Some people have no clue and examples are good to make it concrete. I also agree with your point. How about if we edit it to: "including some people with reading disabilities such as dyslexia"? {Shawn}
  • [done] Question: In the pros and cons section, is the Con for turning off the color supposed to be "Imprecise does NOT provide contrast ratio value?" It currently reads as follows:
    "Turn off color. The tool shows the page in grayscale.
    Pro: Gives you direct experience.
    Con: Imprecise, does provide contrast ratio value." {Jan}
    • yup. good catch! {shawn}
  • [deleted it] To check contrast with IE WAT - finish instructions
    • 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...
      • Is this a case where an illustration might be helpful? Show the table and show how the table-based output relates to whatever is onscreen? {Sharron 11 Nov}
      • I'm pretty certain the JuicyStudio table which opens in a new tab/window does not link back to the tested page and the only way to find where the colours are mapped is by mapping the nodes to the HTML (or doing some visual identification) {Andrew, 15 Nov}

Resize Text

  • [EOWG safari user:][Anna Belle] keyboard shortcut needed:
    From the menubar... select View > Zoom Text Only.
    Or, with the keyboard: [@@ keyboard for this in Safari???]
  • [done] keyboard:
    • [done] 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.{Suzette}
      • I just tested it in FF 25 and the keyboard behavior was dependent on whether or not I had "Zoom Text Only" selected. When it was not selected, then both Ctrl+[+] and Ctrl+Shift+[+] did page zoom including images. When it was selected, then both keyboard combinations did text only. (tangential note: Ctrl+Shift+[-] didn't work with either menu setting) {Shawn}
      • My FF test matches Shawn's findings, though it should be noted that Ctrl+Shift+[+] only works on the keys above the alpha keys not on the number pad keys, where only Ctrl+[+] and Ctrl+[-] work. {Bim, December 12}
      • found confirmation of this in 15 Nov minutes
    • [closed] 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}
      • IE scroll wheel for me scrolled page up & down - did not change zoom {Shawn}
      • In IE, hold down the Ctrl key while using the scroll wheel to control text size. This results in text zoom potentially without horizontal scroll, (images are zoomed too, so wide images will still force horizontal scroll). Anthony mentioned this in a meeting a few weeks ago. {Bim, December 12}
  • [done] A minor edit change: In the firts item at "What to check for" say: "A common problem is that text is in images and it doesn't get bigger" and it should say: "A common problem is the text is in images and it doesn't get bigger" {Emmanuelle}
    • I think this is not substantially more clear than the previous. How about a completely different approach? Perhaps something like "A common problem occurs when text is not presented in a real text format but is actually an image of text. In such a case, when text zoom is used, the size of the image is not changed and so the graphic of the text does not enlarge." {Sharron 11 Nov}
    • +1 for Sharron's revision - I think that makes it a bit more clear {Jan}
    • How about: "All text gets larger. (A common problem is that text is not provided as actual text format but instead the text is in an image. Text in images does not get larger when users increase text size.)" {Shawn}
      amended & OKed EOWG telecon 13 Dec

Keyboard access and visual focus

  • comment {name}
  • [Jan - does the new second paragraph under Keyboard access and visual focus work?] We might want to consider providing a quick example of what visual focus might look like in the introduction of this section - it's explained in the what to check for, but not earlier. I recently had to explain what this meant to a very experienced developer, so if Easy Checks are for beginners, this might need some additional explanation in the introduction. Maybe consider adding something like, "Visible keyboard focus may look like a dotted-line or colored-line box around elements as you tab through the site." {Jan}
    • I tried moving the last sentence of the intro paragraph into a new paragraph, adding text explanation similar to your suggestion, and moving the illustration up to the intro. Does that work? {Shawn}

Forms

Forms in WAI draft page

Comments after 11 December

@@@@@@@@@@@@@@@@@@@@@@@@@ add note able this section hard OK to skip

  • comment {name}

Comments after 14 June

  • [done] 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}
    • 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}
    • Yes, +1 to Bim's suggestion {Sharron 11 Nov}
    • huh? where does it say "be WCAG another way"? maybe that was a typo in an earlier draft? {Shawn}
    • comment {name}
  • [removed] "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? {Shawn, 17 June}
        • 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?
        • Response from Sharron on 11 Nov: Can we advise the use of a free screen reader - NVDA or the JAWS demo?
        • Response from Andrew on 15 Nov: Sharron, I think asking someone to use a screen reader is a big ask in Easy Checks. Sorry, I don't have an alternative suggestion.
        • Response from Name on Date: comment
      • 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}
        • comment {name date}
  • [illustration] 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}
  • [done] 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}
  • [done] Reconsider: are the labels checks are too hard for Easy Checks? (Suzette say more here? : I'm trying a typical college application form with no apparent track record on accessibility: http://www.newham.ac.uk/pages/studentshomepage/findacourse/onlineapplication. The tabbing seems to work, including the drop down boxes. {Suzette responded:}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?)
    • Forms are one of the most barrier-ridden elements of pages, a common reason that web sites are NOT accessible and one of the most formidable challenges when done incorrectly. I am strongly in favor of finding a way to include basic forms testing even if we carve out some very simple tests and make a host of qualifications. {Sharron 11 Nov}
    • I agree with Sharron - we really do need to include some forms-checking in our Easy Checks. My simple suggestion to people re testing for form labes being associated is to try clicking the lable with the mopuse and if the focus jumps into the form control, then probably ok (not definitive, but an easy check) {Andrew, 15 November}
  • [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}
    • Must we include both browsers? If so, I will +1 to the new explanation. If not, I am in favor of omitting the second suggestion for FF in the interests of avoiding still more noise in this section. {Sharron, 11 Nov}

Earlier comments still open 18 June

  • heading for this section simply "Forms?" or more?
    • Currently the section covers: Keyboard access; Labels; Required fields and other 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}
    • +1 to "Forms, Form Labels, and Error Messages." {Sharron, 11 Nov}
    • -1 to "Forms, Form Labels, and Error Messages" because it's control labels (not form labels) and the error handling is more than messages. Personally I'd like to keep it simple with just "Forms"; however, I'm OK with more detailed title. How about:
      Forms, Labels, and Errors
      ? {Shawn}
    • +1 to "Forms, Labels, and Errors"{Bim, December 12}
    • +1 to "Forms, Labels, and Errors"{Sylvie, December 13}
    • +1 to "Forms, Labels, and Errors"{Paul, December 13}
    • +1 {several in 13 Dec EOWG minutes}

open items on forms

  • [OK] 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 (months+) before it gets implemented.
    • Why will it take "a while" for that change and what are the parameters for that timeframe? What is needed...programming resources? a volunteer? group consensus? Making that change in BAD is by far the best solution, so maybe we can focus on getting that done. {Sharron 11 Nov}
    • I agree with Sharron, we should continue to use BAD. Any idea what is causing the browser to not have focus go to the error messages? What browser / version is this occurring in? {Paul, 11/21}
    • We do not have resources for updating BAD right now, so that's not an option. The question is do we need to remove the testing on BAD all together because this is not working? {shawn}

new text

[done?] 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:

[OPEN] How to check for implicit (aka embedded) labels:

Using the Mouse:

  • If label is present:
  1. Place the mouse over the label and right click.
  2. A menu will appear; Choose the Inspect Element option
  3. The label code will appear. If it has a "for=formID" attribute the form / control passes.
  4. If the form / control HTML occurs inside the scope of the label element, the form / control passes.
  • If label is not present
  1. Place the mouse on the form / control and right click
  2. Check for a title attribute. If a title is given the form / control passes.
  3. Check for a value attribute. If a value is present the form / control passes.

I think that handles all programmatically determined cases. {Wayne, 21 November}

Comments:

  • Wayne, I put this in the wiki as you requested and made the change from "name" to "value" in the second section - "If label is not present." Your most recent post to the list reverts to using "name". Which is correct? {Sharron, 21 November}
  • Also, since H65 says title may be used "when the label element cannot be used" shouldn't we make that qualification clearer? {Sharron, 21 November}
  • Finally, I think the next version of explanation of implicit forms that you posted to the list begins into that territory of complexity that has Suzette tearing her hair and asking us to leave Forms out of Easy Checks altogether. Can we keep the simple, early version for the sake of the "Easy"part of Easy Checks? {Sharron, 21 November}
  • How do this without the mouse? {Shawn}
  • I reviewed the 11 Nov minutes and still don't understand the motivation for this new section... {Shawn}
  • EOWG discussed on 13 Dec and Wayne agreed (by phone separately) that this is not an Easy Check based on our checks criteria {Shawn 13 Dec}

multimedia

  • [EOWG - open action] [Paul] 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.)
  • [done] "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?n
    • 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}
    • first link already includes "People who are not proficient in the language who find it easier to read than listen." also added a link to Captions for Literacy. {Shawn}
  • [done] "Check that transcripts include all audio information, including dialogue with the speakers identified, and all important sound [repeat examples above or not?]."
    • Do not repeat examples, but maybe OK to point to them or make a short reference. {Sharron, 11 Nov}
    • Turned out shorter to repeat than to point to reference. In case people jump to that section, how about repeat? We'll see how it works on final review... {Shawn}

Plain Content View


[EOWG open] What to call this section?

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

Latest proposal: Basic Structure Check

Brainstorms

  • 13 Dec minutes (includes discussion of an acronym)
  • 29 Nov minutes
  • 22 Nov minutes
  • Nov e-mail thread
  • Stripped Linear View
  • Unstyled Linear View
  • Plain Content View
  • 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
  • ...

Nov & Dec 2013 Comments

  • comment {name, date}
  • Jan mentioned that whatever heading we use might become a widely-used term. Alan noted that the check does 3 things, but our latest heading only covered 2. That got me thinking... how about trying an acronym? {Shawn 12 Dec}
    brainstorms:
    • LOIS or Lois — Linearize, turn Off Images and Styles. see draft of Lois View intro paragraphs (I think of Lois Lane of Superman, other Loises :-)
    • LADIS — Linearize And Disable Images & Styles
    • LANIS — Linearized And No Images or Styles
    • DISL — Disable Images & Styles, Linearize
    • ...[add your ideas on ways to arrange the words into pronounceable acronyms:-]

    general comments on the acronym approach:

    • I like the idea of an acronym. I don't like the "stripped" use either. LOIS or LADIS sounds good to me. Either the choice is, we should keep the explanation about who uses linearized way without styles and images. {Sylvie, 13 December 2013}
  • I think we should not use "stripped" because of possible very bad associations. {Shawn}

Previous 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}
    • Current title of "Plain Content View" may still have the connotations of "Plain Text" that we tried to avoid. I like moving in this direction. {Sharron 11 Nov}

Next Steps

  • comment {name}


Internal Notes

Easy Checks - Illustrations moved to its own page.

Misc:

  • comment {name}

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-Dec-13&oldid=7673"