Tutorials/Archive

From Education & Outreach
The information on this page is outdated and archived from Tutorials.


Draft Tutorials Schedule

Approach:

  • Finalize UI
  • Move existing content into new UI
  • Set up Github
  • Prioritize which topics to do next

Goals:

  • Complete the Images tutorial asap, hopefully before CSUN, i.e., by March 7th.
  • Have good work prepared for EOWG f2f at CSUN

Note:

  • For final publication approval, EOWG usually needs at least 1 full week across a weekend.

Schedule:

  • Jan. 31 to Feb. 7: Finish new UI, start Github repository, prioritizing possible topics
  • Feb. 10 to Feb. 14: Put UI on w3c site, send to EOWG by Wed 12. {? Moving existing content into new UI. or wait for possible UI changes from EOWG ?} Work on Images tutorial content.
    • Feb. 14 teleconference: UI review. If needed: Images content specific question for EOWG before drafting.
  • Feb. 17 to Feb. 21: Finalize Image tutorial content. Send to EOWG by Wednesday 19.
    • Feb. 21 teleconference: Images tutorial changes. If needed: review updated UI.
  • Feb. 24 to Feb. 28: Any changes to images tutorial based on EOWG feedback. Send to EOWG survey for Images tutorial publication approval — for 25 Feb - 4 March review period. Prep planned topics for EOWG discussion.
    • Feb. 28 teleconference: Planned topics overall, and work for f2f
  • Mar. 3 to Mar 7: Working on further tutorials.
    • Mar. 7 teleconference: If needed: discuss comments from Images tutorial survey. Refine plans for tutorials at f2f.
  • 11 March - publish Images tutorial. (announce?)


[DONE {Eric, 2014-May-05}] Drafts in place and announcements March 2014

EOWG:

  1. The main tutorials URI is: www.w3.org/WAI/tutorials/. Eric's recent work has been at an /EO/Drafts URI. Are you OK with moving Eric's latest revisions to the main URI — keeping "Draft" on all pages until EOWG approves them.
  2. Are you OK with doing future edits at that main URI, as long as the pages are marked "Draft" (and where there are substantive or significant edits not reviewed by EOWG, the pages are marked "Editor's Draft" and there is a note about them not being approved by the WG)?
  • Yes, I think it is fine to move Eric's recent work to the main URI with "Draft" designation and continue to edit it there. {Sharron, 6 March 2014}
  • +1 {Vicki, 6 March 2014}
  • +1 {Andrew, 7 March 2014}
  • +1 {Bim 07 March 2014}
  • comment {name 00-mon-2014}

Thoughts on announcing the Tutorials (as early Drafts) next week before CSUN?

  • I am of two minds about the announcement. I very much like the idea of announcing at CSUN given the kind of gathering it is. But I wonder what is the actual benefit to having an announcement when the tutorials are still in such draft form and only 2 have been drafted? We may want to do more of a "soft launch" approach at CSUN and wait until the tutorials are more realized before doing an official announcement. {Sharron, 6 March 2014}
  • +1 {Vicki 6 March 2014}
  • I don't think there should be an announcment - it's too early in the process as Sharron says with only two drafted at this stage. {Andrew, 7 March 2014}
  • I agree with Sharron and Andrew. {Bim 07 March 2014}
  • comment {name 00-mon-2014}

Cover page

Cover page

For EOWG discussion

  • Summary — comment {name, 00-month-2014}
  • [DONE {Eric, 2014-May-05}] Do we need to provide some background -- e.g., links to Accessibility intro, Accessibility Principles, spell out WCAG on first reference? What if someone lands here without much knowledge? {Shawn}
    • [DONE {Eric, 2014-May-05}] I think both make sense, I have included long name for WCAG and have to think how to incorporate the other resources. (Although I think most people will not get to the tutorials via the front page, it is important to consider.) {Eric, 2014-04-02}
    • [DONE {Eric, 2014-May-05}] Agree lots of people won't come through the cover page... actually, that might be a bigger issue. Do we need something on the first page of each tutorials suggesting that people go to the cover page to get context? {Shawn, 2-Apr-2014}
    • [DONE {Eric, 2014-May-05}] +1 to a link to more background resources from the Tutorials Overview page {Sharron, 03-April-2014}
    • [DONE {Eric, 2014-May-05}] {dboudreau, 4-Apr-2014} +1 to a short introduction before every tutorial to frame it within the whole project.
  • [DONE {Eric, 2014-May-08}] Framing the tutorials — The first sentence "These tutorials provide practical guidance..." seems a bit abrupt. Since Eric also mentioned the likelihood that people will enter from other than this cover page, perhaps we could consider developing more of a framing sentence that could be used elsewhere? Something like: "This resource is a set of interrelated tutorials created to provide practical guidance...etc." Then, on each of the "Concepts" pages, we might begin with "This tutorial is one of a set of interrelated resources created to provide practical guidance for creating websites that meet WCAG 2.0. More information about the full suite of resources is found on the Tutorials Overview page." {Sharron, 03-April-2014}
    • +1 Sharon {Vicki, 03-April-2014}
    • +1 Sharon {Anna Belle, 03-April-2014}
    • +1 {Howard, 04-April-2014}
    • +1 to Sharon {Bim, 04-April-2014}
    • +1 {Paul, 10-April-2014}
  • [DONE {Eric, 2014-May-05}] Seems like there needs to be more guidance on current location. Maybe next to tutorial heading it should say "Tutorials - Overview" instead of just "Tutorials." Also, nothing in the navigation menu at left indicates that this an introduction or overview page. {Howard, 04-April-2014}
    • [DONE {Eric, 2014-May-05}] +1 to Howard's suggestion. The content heading needs to be more specific; another option might be "Tutorials Introduction"{Paul, 10-April-2014}
  • Minor style suggestions.
    • [DONE {Eric, 2014-May-05}] Current text: "They are useful to people in various roles, including:" Suggested change: "They are useful to a variety of users, including:" (just a proposal for simpler text).
  • [DONE {Eric, 2014-May-05}] *Current text: "Web trainers can get compelling examples..." Suggested change: "Web trainers can find (or obtain) compelling examples..." {Vicki, 03-April-2014}</span>
    • [DONE {Eric, 2014-May-05}] Current text: "Web trainers can get compelling examples..." Suggested change: "Web trainers, who can find (or obtain) compelling examples..." {Howard, 04-April-2014}
    • [DONE {Eric, 2014-May-05}] WAI logo needs to link to http://www.w3.org/WAI/ - currently links to W3C home page {Andrew, 04-April-2014}

Editorial

(might not need EOWG discussion)

  • Summary — comment {name, 00-month-2014}
  • [DONE {Eric, 2014-04-02}] Grammar — Opening para should read - "These tutorials provide practical guidance, with examples, for creating websites that meet WCAG 2.0. They are useful to people in various roles, including:" {Andrew, 28-March-2014}
  • [DONE {Eric, 2014-04-02}] welcome ideas box — change "this (publicly-archived) mailing list" to include the actual e-mail address {Shawn}
  • [DONE {Eric, 2014-04-02}] WCAG link in first sentence - change link to the WCAG Overview page. {Shawn}

minor wording suggestions:

  • [DONE {Eric, 2014-04-02}] "for many very common development challenges" -> "for common development challenges" {Shawn}
  • [DONE {Eric, 2014-04-02}] "Web designers can learn how to create elements and overall composites that are easy to later code accessibly." - could use clarification. I'm not really sure what it's saying and it was a bit hard to read. {Shawn}
  • [DONE {Eric, 2014-04-02}] "Web trainers can get compelling examples to teach people about accessible web design." Do we want to say "design and development"? {Shawn}
  • "Project managers can gain understanding of principles needed to plan accessible websites." We should differentiate this from tings like our Accessibility Principles and Implementation Plan resources. Maybe it should be like "Project managers can gain understanding of accessibility issues to help with project planning." {Shawn}
    • I’ve made a change. {Eric, 2014-04-02}
  • [DONE {Eric, 2014-04-02}] "To ensure that you meet the requirements" -> "To ensure that you meet the WCAG requirements" {Shawn}
  • [DONE {Eric, 2014-04-02}] "Examples are HTML-based," -> "Most of the examples are HTML-based," {Shawn}
  • [DONE {Eric, 2014-04-02}] "Send any ideas, suggestions or comments" -> "Please send any ideas, suggestions, or comments" (added please and a comma :) {Shawn}
  • [DONE {Eric, 2014-04-02}] "or contibute <a>to the code directly on Github</a>." -> "or contribute to the <a>code directly on Github</a>." (fix typo & move link) {Shawn}
  • The sentence "They are useful to people in various roles, including:" does now flow into the bullet points. Could add ", who" after each role to make it work grammatically. {Liam, 04-April-2014}

User Interface Design

Draft for review (updated Friday 27 Feb): http://www.w3.org/WAI/EO/Drafts/tutorials/images/

Status and Known Bugs

  • [DONE {Eric, 2014-May-08}] Footer - The footer also needs some work.
  • [DONE {Eric, 2014-May-05}] Links - Some links might not work (especially links beyond the project), this will be fixed next week also.
  • [DONE {Eric, 2014-May-05}] previous comments - Some done and some still open from 13-15 Feb
  • [DONE {Eric, 2014-May-05}] Header - The header should be more WAI-like, but I have not come to a conclusion how that should work out in the end. Suggestions welcome.
    • [DONE {Eric, 2014-May-05}] I think this version is rather good. {Eric, Feb. 28}
  • Content
    • The content is almost everywhere the same as before, I made some code examples fit better in the new layout.
    • Especially that means that the results of the images tutorial survey are not yet included.
    • Long code examples (like in the tables tutorial) are missing, they will make their come back next week.
  • [fixed 14 & 19 Feb] Navigation
    • The navigation is not working optimally, specifically: the main pages (images/tables) don’t have the full navigation yet.
    • This means they are also excluded from the next/previous navigation that is on the other tutorial pages.

Feedback 12+ March

  • In re. image in upper right corner, the shading of the W3C doesn't work with this flat design. I'd suggest changing it to the flatter image used (for example) in the upper left of http://www.w3.org/WAI/ . {Anna Belle 3-April-2014}
  • [DONE {Eric, 2014-May-05}] Do you mean the following to be the lead paragraph on the cover page? "The tutorials here are not exhaustive...." I'm unclear because of the bold DL;DR that precedes it. In you do, I would strongly suggest demoting this clause to a much less prominent place. It makes me want to leave the tutorials altogether, whereas if it were at the end of the page I'd be fine with it. {Anna Belle 13-March-2014}
    • [DONE {Eric, 2014-May-05}] +1 {Sharron 15-March-2014}
  • [DONE {Eric, 2014-May-05}] A minor point about the cover page: IMO the final content paragraph needs space between it and the brownish line that begins the footer. {Anna Belle 13-March-2014}
  • [DONE {Eric, 2014-May-05}] Editorial: little typo: "usefull" - should be "useful" {Vicki 13-March-2014}
  • [DONE {Eric, 2014-May-05}] Editorial: little typo: "guidence" - should be "guidance" {Vicki 13-March-2014}
  • [DONE {Eric, 2014-May-05}] A very minor point: http://www.w3.org/WAI/EO/Drafts/tutorials/ - paragraph starting "Note that these tutorial...", there are two mentions of "web content" and "web contents" - I'd stick to singular, i.e. "web content" in both cases. * {Vicki 13-March-2014}
  • [DONE {Eric, 2014-May-05}] Proposal for slightly modified wording. Instead of "the range and diversity of web content and applications used in websites make it impossible to cover all situations", suggested wording "the range and diversity of web content, applications and changing web technologies make it impossible to cover every situation". {Vicki 13-March-2014}
  • [DONE {Eric, 2014-May-05}] Proposal for slightly modified wording in order to avoid repeating "cover all situations". Instead of "You will find practical guidance and examples of accessible web page contents and interactive widgets, but it won’t cover all situations", suggested wording "This tutorial will provide you with practical guidance and some examples of how to create accessible web content and interactive widgets". {Vicki 13-March-2014}
    • [DONE {Eric, 2014-May-05}] This may be the place to move the lead paragraph comment, as suggested by AB. I like Vicki's wording here and would only add: "It is not however meant to be exhaustive and to cover all situations (or techniques?)" {Sharron 14-March-2014}
  • [DONE {Eric, 2014-May-05}] Suggested change to last paragraph: "Examples are provided in HTML, which is used to demonstrate the different techniques in a widely understood way. The underlying principles can be extended however, and applied to all formats used to present information over the Web."{Sharron 14-March-2014}
  • [DONE {Eric, 2014-May-05}] Following up on conference all assignment.... How about this for list of roles on Tutorials cover page "Web designers will learn how to create elements and overall composites that are easy to later code accessibly" (to be added right below the Web developers' bullet. {Anna Belle 14-March-2014}
  • {name 00-March-2014}

[DONE {Eric, 2014-May-05}] Feedback on 4 March version

  • Changes: (see on Github)
    • Add visited link color
    • Space before lists
    • Permalink only in the main content area
    • Correct typos in Images -> FAQ
    • Create beyond page
    • Fix wrong navigation heading
    • Add Attribution Page to Footer
    • Fixed typo in Textual Images Tutorial
      • also: Remove unnecessary code
      • also: Add Link to technique C22
    • Add new image for search example, better alignment
    • Open Issues that should be done before CSUN

Comments:

I need feedback on the following issues:

[DONE {Eric, 2014-May-05}] Image in Informative Image, Example “Image conveying succinct information”
  • Are we happy with an image like that or do you have other ideas. The photo also has an icon for push and rotate counter-clockwise to open, which we need to reflect in the text. Also, while the photo is shot by me, the icon may be under copyright. Suggestions, especially for copyright-free alternatives are welcome!
    • This illustration is OK with updated alt and other associated text about 'push and twist'; an alternative (I'm partial to manhole covers etc) is http://www.hamiltonianartists.org/wp-content/uploads/2012/06/6-Twist_to_Open_TMT-1024x682.jpg {Andrew, 2014.03.05}
    • Agree that image needs more accurate alt to include 'push and twist.' Otherwise, it seems good. Not sure about copyright, and have no other similar image to offer. {Sharron 5 March}
    • OK for the image - the only reflection I have is that maybe the top is too much in the shadow. {Vicki, 5 March}
    • EOWG Resolution: Keep the image, adjust text. {Eric, Mar. 07}
[DONE {Eric, 2014-May-05}] Alternative approach added to the textual image example “Image of styled content with decorative effect”
  • What do you think about that section? Does it need more descriptive text or is it already understandable?
    • OK as is {Andrew, 2014.03.05}
    • Yes, this is good.{Sharron, 5 March}
    • +1 {Vicki, March 5}
    • EOWG Resolution: Example is fine, keep. {Eric, Mar. 07}
  • I’ve added a note that we don’t display vendor prefixes, should that be described? If so, would it make sense to have some kind of glossary on an additional page?
    • I don't think it needs describing, this an advanced alternative and those taking this approach should understand or be able to figure it out.
      As a separate comment - the RHS note mention browser support. Is there a list of supporting browser we can point to? {Andrew, 2014.03.05}
    • Since vendor prefixes are mentioned here, they should be afforded a brief description and/or a link to more information. {Sharron, 5 March}
    • No comment {Vicki, 5 March}
    • EOWG Resolution: Add link to vendor prefix description, possibly CSS specification. {Eric, Mar. 07}
[DONE {Eric, 2014-May-05}] MathML demo
  • The MathML part of that example isn’t working visually in any browsers, but it maybe nice to have in certain environments. How does assistive technology interpret HTML embedded Math ML?
    • Jeanine Lineback is the most experienced screen reader user on our team. She said "It read 0.3333 with JAWS V14X but did not read at all with NVDA." {Sharron, 5 March, 2014}
    • No Comment {Andrew, 2014.03.05}
    • No comment {Vicki, 5 March}
    • no comment {Shawn 6 March}
    • EOWG Resolution: Remove the example from the page until we know more about the capabilities of AT {Eric, Mar. 07}
[DONE {Eric, 2014-May-05}] ARIA Example
  • [EOWG?] I'd love to have a convincing ARIA example ready, but can’t think of one from the top of my head. The only place I could imagine one is to add to the Image Groups Tutorial, wrapping the stars into something with role="group", using role="presentation" on the images and aria-label on the wrapper. But that feels a bit like a forced example, as the solution without ARIA is so simple. So: Can you think of a good ARIA example together with images? I search for good use cases of aria-label/aria-labelled-by/aria-described-by/others that aren’t easy to implement without ARIA.
    • No suggestion, but as star rating are often produced dynamically is ARIA easier to program? Does go against our WCAG feedback about ARIA instead of 'akt' though. {Andrew, 2014.03.05}
    • What about a thermometer, perhaps during an online science experiment/demo, with a rising number? That's not an Image Group, but could be a good place to use aria {Sharron, 5 March 2014}
    • No suggestion to offer. Star rating sounds good to me. {Vicki, 5 March}
    • Comment {Name, Date}
[DONE {Eric, 2014-May-05}] Notes style
  • [EOWG?] Shawn and I got some discussions about the notes. What do you think? Do they stand out too much?
    • No, I think they are just fine now (after the changes you made) {Shadi, Mar 5}
    • +1 to Shadi :) {Andrew, 2014.03.05}
    • +1 I like this treatment, too{Sharron, 5 March 2014}
    • +1 {Vicki, 5 March}
    • Please see my latest (5 March) comment in the discussions about the notes. I don't feel super strong about it, but probably stronger than others. :-) {Shawn, 6 March}
[DONE {Eric, 2014-May-05}] Also: General feedback:
  • Overall, excellent work! {Andrew, 2014.03.05}
  • Check the quotes in the FAQ section - some aren't matched. {Andrew, 2014.03.05}
  • Would be nice to include a decision tree like Dey Alexander has done - I'd be happy to approach her to reuse or adapt. {Andrew, 2014.03.05}
  • Looking really good - well done! {Vicki, 5 March}
  • Comment {Name, Date}

Feedback on 27 Feb version

[DONE {Eric, 2014-May-05}] Feedback on 21 Feb version

  • permalink - I like the idea that we provide "permalinks"; however, I think it adds clutter and a lot of people won't know what they are. What is the least cluttering/intrusive/confusing way to provide them? Is it worth it? {Shawn}
    EOWG: What do you think?
    • I think the people the tutorials aim at do know what a permalink is. But we could use an icon to have them not stand out so much. {Eric, Feb. 27}
    • I think it's great to have these, and don't think these tiny icons add clutter at all. For those who know them, they are useful. Others may learn about them from these tutorials. {Shadi, Mar. 5}
    • Comment {Name}
  • [addressed] space before lists - For simple lists, I strongly prefer there to be no space between the sentence that introduces the list and the first list item. {Shawn 21 Feb} e.g., 
    The list below is too far away from this sentence that introduces these items:

     * The first item
     * Second item
     * And third item

    The list belongs with this sentence so let's not have space separating this sentence from these items:
     * The first item
     * Second item
     * And third item
    • It is very unusual to have no space in front of a list. And I (personally) find it harder to read… I now have half the space between a list and the preceeding paragraph, and I hope that suits us both ;-) {Eric, Feb. 27}
    • Also, I have can’t determine if a list is “simple” in CSS, and using classes is hard to maintain, too. {Eric, Feb. 28}
  • Title tag separators - The title tag separators are a pipe (|), e.g. "Images Concepts | Tutorials | WAI Web Accessibility Tutorials". I really like the title stack like this, but notice that (at least some places) on the W3C site the separator is a hyphen. Personally, for old-fashioned editorial reasons, I have a slight preference for a hyphen. But it's a minor point. {Anna Belle, Feb. 27}
    • I usually use the pipe (|) but we can also use en or em dashes (– or —) or guillemets («). {Eric, Feb. 28}

[DONE {Eric, 2014-May-05}] Feedback on 19 Feb version

  • Wow! - Beautiful! Clean and airy. Love the large fonts, ample white space, and pale gray color scheme. {Anna Belle - Feb. 20}
  • breadcrumb icons - Current icons are the same as the previous & next, which I think they should not be. I would suggest just plain greater than sign (>) {Shawn}
  • left navigation - menu headings - Maybe a little space between the menu heading and menu items so that it aligns more with the main content h1 and so that it is more evident. {Vicki - Feb. 21}
  • [addressed]heading - "Images" - Now if I say the heading is kinda large, will you get cross with me? {Vicki - Feb. 21}
    • I think it works quite well, we need more hierarchy in the page, and the large headings provide that. {Eric, Feb. 28}
  • [addressed in EO call Feb. 21] left navigation - menu headings - Perhaps consider using bullets instead of numbered list. When I first looked at the left navigation it seemed that the right padding was too large but just looked again and the extra padding is not there. I think the navigation menu is very readable but perhaps lacks some cues to identify it as a menu. I would suggest bottom borders below each menu item at least to make it look more like a conventional menu. Not sure I like the font - it that the standard wai or w3 style?{Howard - Feb. 20}
  • [addressed] left navigation - The two highlighted menu items (a little difficult to explain): the dark grey indicator before the left menu "Image Concepts" does not have a number, whereas lower down, there is a number on "Images" under the heading "All tutorials". Probably, just a bug.{Vicki - Feb. 21}
    • This is intentional as Image Concepts and FAQ are not really tutorials. I removed the numbers in front of All Tutorials. {Eric, Feb. 28}

Feedback 13-15 February

  • nice! - really like lots of this! good work! {Shawn}
  • +1 Bravo - Vicki

Headings

  • [addressed] Page heading stronger - In this draft, the "Web accessibility tutorials..." is very strong at the top; the title of the page, e.g., "Decorative Images" is much smaller; the title of the tutorial "Images" is only quiet in the navigation. Maybe tweak the visual design so: 1. "Web accessibility tutorials..." looks more like a masthead and less like the title of an individual page; 2. the tutorial title (e.g., Images) is more clear -- maybe just make stronger in the nav &/or maybe add to the <h1> somehow, e.g., like "How People with Disabilities Use the Web in Stories of Web Users; 3. Make the specific page title/heading bigger. {Shawn}
    +1 {Vicki, February 15}
    • I made some adjustments in dev. {Eric, Feb. 19}
  • [addressed] <title> - current draft has "[specific page] | WAI Tutorials" maybe instead "[specific page] | [Topic] Tutorial", e.g., "Decorative Images | Images Tutorial" or add "Web accessibility tutorials" at the end? {Shawn}
    • Could this be resolved with breadcrumbs {Vicki, February 15}
    • This was a bug, already fixed in dev. {Eric, Feb. 19}
  • [addressed] Headings color - some of the headings are blue. On the Web, blue is affordance for clickable. However, these headings are not clicklable. Therefore I suggest not making them blue. {Shawn}+ 1 {Vicki}
    • Point taken, fixed in dev {Eric, Feb. 19}

Navigation

  • [addressed] Left nav - numbering - I have mixed feelings about the numbering. On the one hand, I ask "why" and on the other "why not". It would be interesting to see the left nav without the numbering and understand the reasoning behind the numbering. {Vicki, February 16}
    • I’ve refined Shadi’s idea of only numbering actual tutorials and not overview/intro and tips pages. Feels cleaner now. {Eric, Feb. 20}
  • [addressed] Nav current page - I would prefer for the background color of the selected page to match the background color of the main content. Also, I would prefer some kind of arrow or chevron ("»" which we use on the WAI website) pointing to the main contents, instead just a bullet at the end of the line. {Shawn}
    +1 for the color of the highlight to match the content area Vicki (February 16)
    • I just had a look, and it doesn’t look good if the background of the current element is the same as the page’s background. It feels broken. (That is one of the reasons I tend to prefer inverted colors for active menu items.) {Eric, Feb. 19}
    • I like the 19 Feb version {Shawn}
  • [addressed] Nav topic - I think the main topic (e.g., "Images") should be left aligned and a bit stronger. {Shawn}
    +1 {Vicki, February 15}
    • Did that (in dev) {Eric, Feb. 19}
  • [addressed] Left Nav (images tutorial) - The navigation headers currently say "Images" and "All Topics". Suggest changing those to read "Images Tutorial" and "All Tutorials". If someone sent me this URL and I'd never seen the page before, I wouldn't know I was on a tutorials page unless/until I saw the page title. Also, the "Tutorials Home" left nav bar with the Home icon did not jump out at me as I would expect, even though it is much darker and physically on top of the other navigation elements.{Paul, Feb 14}
    +1 Vicki (February 16)
    • I now (in dev) call the top box “Image Tutorial Contents:” and the bottom box “All Tutorials:” – I hope that makes more sense. {Eric, Feb. 19}

Misc

  • Note style - Current style has Notes with an "i"-in-a-circle icon, indented, and "Note:" bold. This serves to really make them stand out. Based on the information design, are these intended to stand out so much? Or perhaps the opposite - they are tangential side notes? {Shawn, Feb 2014}
    • Made the font lighter and reduced the font size {Eric, Feb. 20}
    • But with the icon and the indentation it still stands out quiet a bit -- actually having the font different color & size makes it stand out even more, imo :-/ {Shawn, 20-Feb-2014}
    • I think the information there is important enough -- they are sometimes really important gems to help understand the examples. I think the current new style is fine. {Shadi, 5-Mar-2014}
    • I really think it depends on my original question: "Based on the information design, are these intended to stand out so much? Or perhaps the opposite - they are tangential side notes?" If they are important points, then it's good for them to stand out; however, if they are tangential side notes, then they should not stand out at all.
      If they important points, then I think go back to the original design -- and do not make the text a different color or size, because that complicates the visual design. (You could unbold "Note" since the icon and indentation makes them stand out enough without it, but I don't have a strong opinion on that either way.) {Shawn 5 March-2014}
  • [fixed] Visited links - Could a visited links style be added. I often find this quite useful especially on sites where there are many links. {Vicki - February 16}
    • Is noted as a bug :-) {Eric, Feb. 20}
  • [closed] Color - main content page - The color of the main content page across devices illustrates some inconsistency which could be bothersome. On Mac, it's fine. However, on a Windows laptop I have using FF, the background appears bluish-light grey which, for me, is distracting and renders the page less readable. Could you consider white for the background of the main content? {Vicki - February 16}
    • The color of the background is #F5F5F5 which is barely not white to enhance readability. Unfortunately every monitor is different and we don’t have much control how colors are shown. Most of the time contrast levels are way up or way down, butchering any color one can use. {Eric - February 19}
  • [done] Footer - Suggest making it smaller font and quieter - maybe lighter font. {Shawn} +1 {Vicki - February 16}
  • [done - wontfix] Width - main content - Can the width of the content area be greater to use up more screen space or is this a limitation of the design requirements? {Vicki - February 16}
    • I aim at a line length that is really good to read, obviously people in the W3C are used to long line lengths as Shadi mentioned this to me as well. There is a WCAG2 Advisory Technique that recommends 80 characters or less on resize, and we got about 100 (depending on your screen size, this is responsive). {Eric, Feb. 20}
  • [addressed] previous & next arrows - I'm not sure if the arrow icons communicate "previous page" and "next page" strongly enough. Might want to have "Previous: [page title]" and "Next: [page title]" as the text? {Shawn} [EOWG: thoughts?]

Open Issues - General

Big Picture Approach

For discussion 19 July

  • Comment {Name}
  • On this first homepage of the image tutorials, may be change the alt text in the navigation menu. Actually called "current page" Images. Prefer "current topic or tutorial" to make it clear that you are in the images topic. {Sylvie, 28 June}
  • It may be useful to add a note after the list of the pages included in the tutorial, saying that you can either read the different pages in the proposed order and clicking on "next page", or choose in the list to read on the types of images that meet your situation. So if you don't use complex images, you don't need to read it. {Sylvie, 28 June}
  • [closed] The Tables FAQ page is not an FAQ - there are no questions! These are great tips, though. Should we rename this page to "Tips", "Recommendations", or something else? {Paul - July 11}
    Reply: Apologies, the Tables FAQ page isn't complete, I plan to change some of the tips to FAQ. I should have removed the prior content (when the page was called "Tips". Will do that now. Thanks. {Bim - June 12}


[closed] For discussion on Friday 28 June

New approach applied to Images tutorial:
After our meeting last Friday, see minutes 21 June we've tried to balance the needs for brevity and detail, so the Images tutorial pages have been reorganized. Please compare this with another section, such as Tables tutorial. Does the new approach satisfy the variety of needs for everyone in the diverse target audience (developer, trainer and manager)?

  • [closed] Restructure and presentation is better/clearer, but maybe the landing page is too bald now :) {Andrew, 28 June}
    Thanks Andrew, the landing page now includes the concepts, users can now read as far down the page as they want but get short information and links to other pages near the top of main content. {Bim - June 12}
  • [closed] I still prefer the images section even if it has been reorganized. I like the overview page. I added some comments below specific to the images tutorial. {Sylvie, 28 June} {Thanks Sylvie, I've now moved your other comments 12 June meeting topic.) {Bim & Shawn - June 12}

Your Return on Effort section

For example, see this draft section in Images, yet none for Tables

What are the pros and cons of including this section? relationship to Business Case?

  • On the page Basic concepts the heading title "your return on effort" is not really clear to me. {Sylvie, 28 June}
  • comment {name}

Open Issues - Topic Specific

[moved] About these Tutorials



Images

  • summary - Comment {Name, 00-Mon-2014}




Tables

Should we not include "Providing a summary" since summary is deprecated in HTML5?



Forms

Under "Overview", "Clear Structure" links to page with the header "Structure". Keep terms/issue consistent.



Topics

Topics Planning Table

Tutorial Topic Complexity (up to 100) Impact on Accessibility (up to 100) Distribution on Websites (up to 100) Priority (Usefulnes
+Distribution)/2
+ Complexity/4) 		Status Notes
Images Image concepts 70 100 100 82.5 Draft
Functional images
Images of text
Informative images
Complex images Add infographics example?
Groups of images
Image maps
Decorative images
Tips and FAQ Wonder if we could rename that to something more descriptive?
Tables Concepts 40 100 90 85 Editor’s Draft
Header Cells
Caption
Scope of Headers Possibility to merge with Header Cells?
Multi-level tables Rename to “complex tables”?
Summary Should be “Table summary” (sounds like it is just a summary of the table topic otherwise)
FAQ
Forms Concepts 80 100 100 80 Editor’s Draft
Labels
Structure Rename to “Form sections”?
Instructions
Error prevention
Error messages
FAQ
Date picker 90 100 100 77.5 — May depend on keyboard control
Tagging in text fields (like Twitter/FB) 75 80 30 36.25 — May depend on keyboard control
Sliders/Carousels Concepts 90 100 80 75 Early Editor’s Draft
Structure
Controls Should reference buttons in forms.
Actions
Scrolling Better “Animation”? Or Automation?
FAQ
Basic Structure Page title 5 100 100 98.75 —
Headings
Information Structure 40 100 100 90 —
Navigation Page navigation 65 100 100 83.75 —
Breadcrumbs 10 100 60 77.5
(Modal) Dialog — 80 100 100 80 — Will use components from forms heavily
Notifications — tbd tbd tbd tbd — –
Hiding & Revealing content Tab panels 15 100 100 93.75 —
Accordions 35 85 80 73.75
Keyboard Control — 45 80 80 68.75 —
Tree Control — 45 80 80 68.75 — Maybe Wilco Fiers can help out here (he created the one in the ASD)
SVG (Infographics?) — tbd 100 85 85 — Maybe we can cover that in the images tutorial
Icon Fonts — 60 100 90 80 —
Generated Content — tbd tbd tbd tbd —

Topics in progress

  • Misc
    • remember to address the comments from the 2013 review survey
    • Descriptive text should be visually different than the actual examples. {Eric}
  • Images
    • Decorative Images
      • Example 1: Too basic? Probably using a different, more complex image like one of those flowery separators to illustrate the point. {Eric}
    • Groups of Images
      • More Examples, especially things like galleries, thumbnails etc.? {Eric}
    • Image Maps
      • I am on the fence if we really need image maps as they are mostly obsolete and people rather use a elements which are positioned with CSS {Eric}
        • Provide another example: Invisible Link positioned over Image? {Eric}
      • Provide another example: Infographics/Diagrams with CSS {Eric}
    • Images of text (http://www.w3.org/WAI/tutorials/images/textual)
      • Example 2: If the logo was part of some kind of image gallery it would make sense to prepend the text “Logo: ” (should probably be in “Group on Images”) {Eric}
      • Example 3: I wonder if the mathematical expression is not too simple to illustrate the point, the alt seems a bit too elaborate {Eric}
    • FAQ: You can’t assume that the alt text (or title) is shown as a tooltip: http://blog.paciellogroup.com/2013/01/using-the-html-title-attribute-updated/ {Eric}
  • Tables
    • Header cells
      • I think even those examples should use thead and tbody elements, as we can then build up on them, plus they are in the dom anyway which is why table > tr is never working. {Eric}
      • Can we have the examples expand inline? {Eric}
    • Multi-level tables
      • Example 1 seems very uncommon to me, better switch with example 2 (which was also in BAD)? {Eric}
    • FAQ
      • The wording in the role="presentation" answer should probably be a bit more toned-down, as there’s a good chance that there are a lot of more issues than “only” that layout table {Eric}
  • Forms
    • Labels
      • Is the asterisk (*) sufficient to denote a required field? what about HTML5/ARIA required? {Eric}
      • Todo: Radio buttons and checkbox examples {Eric}
    • Error Messages
      • How to present good error messages that help completing the form quickly. {Eric}
  • Carousels
  • ...

Possible Topics

  • Components - focused tutorials using different technologies (HTML4, HTML5, WAI-ARIA, ...)
    • Forms: input elements, form layout, pull-down menus, error messages, ...
    • Tables: layout tables, simple data tables, complex data tables, ...
    • Images: decorative images, charts and diagrams, photos, illustrations, ...
    • Page titles and headings
    • Navigation: in-page navigation, on-site navigation, cross-links, ...
    • Keyboard control: device independence, tab order, reading order, ineffictive use of tabindex (or should this be under "Navigation"?) ...
    • Information structure: (prime content first)in page titles, labels, headings, links, ...
    • Widgets:
      • sliders
      • accordions
      • menus
      • dials
      • carousels
      • date pickers
      • tab panels
      • tree controls
      • modal dialogs
      • star rating selectors
      • address/contact information {Eric}
      • breadcrumbs {Eric}
      • tagging in text fields (like Twitter/Facebook) {Eric}
      • autocomplete text fields (similar to the above) {Eric}
      • buttons like “like buttons” (feedback, state) {Eric}
      • “real buttons” (advisory for the usage of button elements instead of spans with aria properties, probably goes best into the forms tutorial) {Eric}
      • icon fonts {Eric}
      • SVG {Eric}
      • infographics {Eric}
      • shopping carts/buying process {Eric}
      • ...
    • ...
  • Technologies - explanatory resources on different technologies (HTML4, HTML5, WAI-ARIA, ...)
    • WAI-ARIA: (We should refer to ARIA in HTML spec as much as possible {Eric})
      • landmarks
      • roles
      • active regions
      • application: when to use, when to avoid
      • ...
    • HTML5:
      • sections
      • menu
      • making compatible with older browsers / issues with AT (Howard)
      • ...
    • ...
  • Audiences - explanatory resources on optimizing website accessibility for different audiences
    • People with cognitive disabilities
    • Keyboard users (with and without vision)
    • Older people
    • People with low vision
    • ...
  • Contexts - explanatory resources on applying WCAG2 in different contexts and situations
    • mobile websites
    • mobile web applications
    • content for digital TV
    • ...

See also: Easy DD potential topics



Archived Notes

Possible Project for UI Design for Navigation

Suggested Design Specs for Tutorials navigation

Goal: An integrated look and feel for the navigation system for the Accessibility Tutorials, now in draft form. No need to redesign the internal content, merely the page framework and navigation. There are three types of pages:

  • Tutorial main page (Current draft of main tutorials page)
    • goal: identify as part of WAI pages communicate related internal sections and chapters
    • design: flexible
    • note: create the understanding that this is a self contained destination, HomePage of a sub-site, need way-finding back to WAI as well as forward and internal among tutorial "chapters".
  • Landing page for each topic (example from landing of Images Tutorial section)
    • goal: provide useful way-finding, both forward through the section in current focus (Next/Previous, etc) and back to the Tutorials Home and away to the main WAI pages
    • design: flexible in harmony with previous
    • note: current numbers were tried as a way to understand the suggested sequential nature of the lessons, but this is not a requirement. The important thing is to give the sense of unity and suggested sequence.
  • Internal page within topics (example from internal page of current draft )
    • goal: look integrated into the overall Tutorial publication, able to note where user is within series of pages, and provide mapping in and out of the specific lesson at hand.
    • design: very flexible in harmony with previous
    • note: include overall general menu as well as mechanism for Next and Previous

Thanks again for your consideration of doing this for the W3C Web Accessibility Intiative Education and Outreach group. We greatly appreciate your help!

20 Nov reply

I'm still unclear whether you would like us to do any visual design as part of this project. I understand you don't want a complete redesign, but is a visual design based on the current WAI/W3C look and feel required?

Another question our UX designers have asked before starting the project is whether the website will have the capability to create dynamically generated content. An example of dynamically generated content is a box with related content that is created based on a set of criteria (e.g. resources that are related to images).

I have included a project plan below. Please let me know if this aligns with what you had in mind.

  • Stage 1: Production of three high-fidelity wireframes (tutorial main page, landing page - topic, landing page - internal page). We'd also include some guerrilla testing which is essentially doing some quick 'out in the wild' user testing with people we know.
  • Stage 2: High-fidelity wireframes will be sent to WAI for feedback and we will take that feedback and update the wireframes. We will discuss with you if any of the feedback will impact on the user experience.
  • Stage 3: Updated high-fidelity wireframes will be delivered to WAI.
  • Stage 4 (to be confirmed): Visual design for the three wireframes

[end reply]

EOWG comments

  • I'm concerned there's a disconnect in the scope. We want visual design with HTML & CSS all ready to go; whereas this ends in wireframes. {Shawn}

Terminology: code or markup?

Pros, cons, considerations?

26 April EOWG minutes

  • support for "markup" — "markup" is more technically correct. non-developers might not know that term, and might know "code" — however, target audience for this is people who ought to know "markup". also, we'll use "code" for things like JavaScript I assume? {Shawn}
  • in Easy Checks we say "headings need to be "marked up" in the web page "code" (e.g., HTML)". Perhaps use similar approach. In the first instances, say something like: "website code, called "markup", e.g., HTML" — then use "markup" throughout {Shawn}
  • my vote is for "markup" - more precise. Code is a very broad term.{Howard May 2}
  • comment {name}

Headings in Concept pages

Each topic starts with a concepts page (forms, tables, images) that currently has two sections headed:

  • Summary
  • Who benefits

Ideas for these headings?

26 April EOWG minutes

First heading:

  • Overview {Bim, Anna Belle}
  • What's in this tutorial (probably not, just brainstorming :-) {Shawn}
  • What you need to do (probably not, just brainstorming :-) {Shawn}
  • comment {name}

Second heading:

  • Rationale {Bim}
  • What are the benefits? (I like rationale too but maybe a little fancy a word){Howard - May 2}
  • comment {name}

Other comments:

  • it's not clear that there are other pages. perhaps have a sentence at the end of the first section something like: "This Forms tutorial covers: [subtopic linked], [subtopic linked], and [subtopic linked]. {Sylvie & Shawn}
  • the links at the bottom of each page to the next page/topic are easy to miss and the menu indicating other sections is off to the left - also easy to miss. The [subtopic] approach sounds promising but would like to see how it would look {Howard - May 2}
  • comment {name}

What to call these things?

Full name

Latest draft:

  • overall title: Web Accessibility Tutorials - Guidance on how to create websites that meet WCAG (which is currently in the latest draft)
  • topic titles: Accessible Forms; Accessible Images; Accessible Tables; etc.

Thoughts?

  • for SEO, this has "how to" and "WCAG" in main title and "accessible [topic]" for topic titles {EOWG telecon 26 April}
  • Whole websites - or the component parts? Just a thought: websites can be huge whereas the tutorials cover very specific design features. Is it possible to convey that the tutorials cover common problems in bite sized pieces rather than suggesting that you are learning about accessibility of whole websites? I would propose using 'webpages' rather than websites in the subtitle. Although I'm not sure if that is a good solution, but is at least a more modest and achievable goal? {Suzette}
  • comment {name}
  • overall title: Accessibility Tutorials - Guidance on how to create websites that meets WCAG (which is currently in the latest draft)
    • need "web" in there somewhere. either:
      Web Accessibility Tutorials - Guidance on how to create content that meets WCAG or
      Accessibility Tutorials - Guidance on how to create web content that meets WCAG {Shawn}
    • my vote is for the latter - prefer the shorter title, longer sub-title {Howard - May 2}
    • I prefer the first with "Web accessibility..." {Vicki - May 3}
    • [done, per EOWG telecon discussion] The term "websites" now replaces "content" in the longer title, see the starting page for example {Bim - May 7}

    Short name

    This should be a single word describing the type of resource so that the user knows what they will find. It will also be part of the URI. Recent suggestions:

    • For me tutorials was fine, but OK for another brainstorming. {Sylvie 20 June}
    • I've seen these types of documents referred to as "articles" at WebAIM and elsewhere. {Howard, 27 June}
    • Comment {Name}
    Previous short name suggestions


  • "Naming the notes" section of the Analysis page
  • 26 April EOWG minutes
  • e-mail thread
  • 12 April EOWG minutes


Formatting

  • Link pointing to next page is much better but still needs to be more prominent - perhaps a large graphic arrow (with alt text). {Howard, 27 June}
    reply: Sounds like a plan. Let's bring it to the group once the overall approach and naming is agreed. As these links are generated dynamically by PHP script, any change will cascade across all pages as soon as it's been applied. {Bim - July 12}
  • [closed] I find the What to do, Why, How, Conformance very hard to read because of the tight spacing — both the line-height and the space between sentences. I realize that I need things more spaced out than "common" so would appreciate other perspectives on this. {Shawn 20 June}
    reply: If the new approach is approved these lists will disappear. Do let me know if you have difficulty with any others though. {Bim - July 12}


Misc

(deleted this timestamp check)


Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Tutorials/Archive&oldid=11076"