Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


Using BAD (Before-After Demo) for Teaching

From Education & Outreach
Revision as of 19:42, 4 June 2012 by Shawn (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Nav: EOWG wiki main page > Curriculum & Course Materials

ROUGH DRAFT of what this page might contain

See the BAD Overview for:

  • About the Demo
  • Demo Contents
  • Brief examples of using BAD for presentations on web accessibility, learning about specific web accessibility barriers, understanding the implications of web accessibility barriers, and writing detailed reports of conformance evaluations.

Hidden Gems

@@ such as:

  • the jokes in the inaccessible version
  • the different ways images are included

Sample teaching/learning exercise for accessible and inaccessible pages

    • Learning outcome: the student developer can identify examples of common accessibility problems and their solutions.
    • Aim: to provide a simple introduction to concrete examples of accessibility barriers and solutions with differences at the code level for student developers with prior knowledge of HTML/CSS


Text, pictures and links

{{@@Sylvie: I wonder if we could not split this exercise in two phases, as it contains many things to do. I propose to have a first part on content : that is text, images and links and a second part on layout}{@@Done_Suzette}}


1. Open the Inaccessible Home page: http://www.w3.org/WAI/demos/bad/before/home.html

2. Identify the main design components of this page:

    • What is the main text content?
    • How many pictures are there?
    • How many links are there?

3. Open the Accessible Home page into a new tab or window: http://www.w3.org/WAI/demos/bad/after/home.html

    • Compare the two visually, do they look similar or different?
    • Using a developers toolbar eg XXXX, disable the images, now what can you see?

4. Pictures: Switch on the Annotations for both versions.

    • Look at the Annotation notes (Before: 1, 2, 4, 8 and 10, After 1, 2, 4, 9 for Success Criteria 1.1.1)
    • Find an image:
      • that is informative to the written content
      • that looks like text
      • that is described as decorative
      • where the description of it is too long, or irrelevant
    • Who is most affected by poorly marked and unmarked pictures? How would they be affected by the inaccessible website?
    • On the accessible website, how has the developer fixed the ‘Alt text’?

{{@@Sylvie: one quick remark: do you think it could be useful to tell the student that an image can serve as an example for several situations? An image that contains text can be a link and it contains important information.}{@@Suzette_I've compared my questions with the images and notes and have simplified this part and removed pictures as links as there was no example of this here. My pedagogic plan for this exercise is observation and reflection but this does leave a question of how much information to give out, and whether to include answers eg from the developers tool listing there are 29 images and 40 links}}

5. Links: Switch off the Annotations for both version

    • With the accessible version, press the tab key – {@@question: does this depend on your browser setting?}.
      • Is each link highlighted in turn?
      • What happens when you try this with the inaccessible version?
    • Switch on the annotations and compare the links on both versions, look for Annotation notes (Before:5 and 7, After: 5 for the Success Criteria 2.4.4 and 2.4.9 on link purpose and 2.4.7 on focus, and 4.1.2 name, role value)
    • Find a link:
      • that is hidden
      • that changes both when you hover over it with the mouse and tab to it
      • that is part of a list
      • that has the same name as another link
      • that has a name that helps you predict where you will go
    • Who is most affected by badly marked links, or where you cannot tab through the links?
    • On the accessible site, discuss how the developer has used different strategies to improve the accessibility of the links?

Layout

Current best practice is to use Cascading Style Sheets (CSS) to define the layout and appearance of website pages. The appearance of any text with a special function such as a heading or a link is (should be)controlled by the CSS.

1. Open the Inaccessible Home page: http://www.w3.org/WAI/demos/bad/before/home.html

2. Identify the layout components of this page:

    • Find the header, banner and footer.
    • How many columns are there?
    • Where is the main navigation?
    • Where is the main content?

3. Open the Accessible Home page into a new tab or window:http://www.w3.org/WAI/demos/bad/after/home.html

    • Compare the two versions visually
    • Using a developers toolbar eg XXXX, disable the CSS, now what can you see?
    • Read the main content carefully and compare the reading order

4. Switch on the Annotation for both versions a. b. Look at Annotation note (Before: 6 and 9, After: 6 and 8, and Success Criteria 1.3.1 and 1.3.2) and compare the inaccessible version with the accessible version.

    • {@@AA: or they could turn style sheets off.}{@@Done_Suzette}


Accessible forms and data collections

Learning outcome: the student developer can identify examples of common accessibility problems and their solutions.

Aim: to provide a simple introduction to concrete examples of accessibility barriers and solutions with differences at the code level.

Who: Primarily developers with prior knowledge of HTML/CSS, also includes some visual inspection tasks for student developers and others with limited or no prior knowledge of HTML who are seeking practical examples of web accessibility practice.

In this exercise we will use the Survey page in both the inaccessible (before) and accessible (after) versions and use the annotations to help identify accessibility issues. More detailed content is available by using the Reports which are included as part of the BAD demo and following the links to the WCAG 2.0 and the more detailed information in the techniques and failures resources.

1. Open the Inaccessible Survey page: http://www.w3.org/WAI/demos/bad/before/survey.html

2. Identify the main form design elements of this page:

    • Are there instructions on how to complete the survey?
    • How many questions are there?
    • How many text entry boxes are there?
    • How many radio buttons are used?
    • What information is collected in the drop down box?
    • What information is provided in the survey results table?
    • Go to the question “Do you want to receive a free newsletter”. Position the cursor at the start of this section and then tab through the fields - is the sequence logical? (Tip: Tab to go forward, shift Tab to go back)

3. Open the Accessible Home page into a new tab or window: http://www.w3.org/WAI/demos/bad/after/survey.html

    • Compare the two visually, do they look similar or different?
    • Go to the question “Free newsletter (optional)”. Position the cursor at the start of this section and then tab through the fields - is the sequence logical?

4. Switch on the Annotations for both versions

Tip: To see the HTML view use your browser 'view source', or developers tools such as Firebug to 'inspect elements'.

Radio buttons: Labelling and position (Before and After: notes 2 and 3, success criteria 3.3.2)

    • How are the radio buttons identified for the user?
    • How are the radio buttons identified in HTML (After: input id, type, value, name, label)
    • When and why would you use a radio button to collect information?

Drop down (select) box: Labelling and organisation of list (Before and After: notes 4 and 5, success criteria 3.3.2, 2.1.1 and 2.4.1)

    • How is the drop down box identified for the user?
    • How are the items listed?
    • How is the drop down box identified in HTML (After: legend, select, id, name, option value)
    • When and why would you use a drop down (select) box?

Text boxes: Labelling and layout of text boxes (Before: note 6, success criteria 3.3.2, 1.3.2, 2.4.3. After: note 6, success criteria 1.3.2, 2.4.3)

    • How is the text box indicated to the user?
    • What information is collected in the text boxes?
    • How is the text box identified in HTML (After: class, label, input id, type, style, size, name)
    • When and why would you use a text box?

Results table: Structure and layout (Before and After: note 7, success criteria 1.3.1)

    • How is the table indicated to the user?
    • How are the rows and columns defined?
    • What type of information is contained in the table?
    • How is the table identified in HTML (After: Class, thead, tr, th, scope “col” and “row” , tbody.
    • When and why should you use a table?
    • When should you NOT use a table?

{@@ Notes: I used a slightly different approach to link to the notes and success criteria - is this helpful. It would help to have an audio file so that users can 'hear' some of the differences and especially where the 'before' version is very messy. Also to explain strategies of filling in forms when using a screen reader. I am not a technie - please help correct any technical errors :)}}

References and Acknowledgements

Acknowledgements

  • {Editor | Primary contributors}: Suzette Keith, ...
  • Other contributors: .Sylvie.. and W3C WAI Education and Outreach Working Group (EOWG) participants.