Web accessibility 2010 v2
Upcoming SlideShare
Loading in...5
×
 

Web accessibility 2010 v2

on

  • 4,450 views

Okay folks, I think we'll get started. Web Accessibility: Principles, Strategies & Tactics. ...

Okay folks, I think we'll get started. Web Accessibility: Principles, Strategies & Tactics.

Sean Yo, BA & MA with a focus on digital media. Despite his youthful facade, he's been at the university twenty years.

Works at subunit of web solutions, for many departments on campus. Has presented many times on accessibility. I give you Mr. Sean Yo.
10:02 AM
Sean: I started my undergrad in 1994, I'll leave the arithmetic as an exercise for the audience. Thank you, welcome. Last year I presented "Real World Accessibility" where myself and Rob Geddes presented a case study on some sites we'd launched with our Web Solutions team. Was gratifying to receive the response, but also seemed that our expectations weren't quite as far behind as we thought. Had a lot of people asking us questions we thought we be assumed.
10:03 AM
We wanted to step back, practice what we preach, start off with fundamentals and not make so many assumptions.

I'm a web analyst with a group on campus called Web Solutions, part of Computing & Communications Services. I'm an accessibility advocate - I chose that word, because it's not "expert". I think it's a challenge to lay down the gauntlet to be an expert.
10:04 AM
Before we get into it, I want to go over some fundamentals. Anyone here seen this abbreviation: A11Y, people who have drank beer with me don't get to answer.

Randy...

Randy: I've seen it, yes.

Sean: That's awesome.

A11Y stands for accessibility. Anyone know why?

Number of characters. Me trying to use this abbreviation more. Good on Twitter.
10:05 AM
So to make sure we're on the same page, what is web accessibility? I like the Wikipedia definition, though it's a week and a half old. "the practice of making websites usable by people of all abilities and disabilities. All users can have equal access to information and functionality".

Very strong, lots to work with, clearly centered on people.
10:06 AM
When we talk about disabilities, four categories: visual, hearing, motor and cognitive. Visual: blindness or low vision, contrast, colourblindness. Hearing: low hearing or deafness. Motor: physical issues, limited or fine motor control. Cognitive: learning disabilities, distractability, focus.

Have to think about why are we doing this? I think our keynote speaker gave us some great information or ideas about why it's important.
10:07 AM
Following all coding best practices, XHTML/CSS, readable whitespace in your code. Pride in craft, but the purpose of a website is to communicate. Ignore accessibility and you're not communicating with a wide audience. Pay attention to website, better for everyone.
10:08 AM
Built environment: ramps are accessibility feature, but useful to anyone. Not going to spend a lot of time on the rationale, I'm going to assume most of us at an accessibility conference see the value. If you need more information, here are a couple of links and a high-level overview of the key points. Most important one is the first one, it's the right thing to do.

Other two: saving resources and Google will love you.

These slides will be up within minutes of the presentation, so don't worry about copious notes.
10:09 AM
So something before I get into the presentation, finish up with a small shift in my thinking lately. Last couple of years, if you read web design blogs and sites, you've noticed there's a new terms; UX for user experience. Usability, more people-centric, tied into specific experience. I like it, moves away from lab tests and checklists. Focus design on people.

I've stopped talking about accessibility, trying to talk more about accessibility experience. It helps remind us and keeps us anchored on people. If there's one thing you take away today, accessibility is all about people.
10:10 AM
People have experiences, checklists don't. Not to say they aren't useful, I use them in accessibility testing and in my life. But they can give you false positive re

Statistics

Views

Total Views
4,450
Views on SlideShare
4,423
Embed Views
27

Actions

Likes
5
Downloads
144
Comments
1

6 Embeds 27

http://www.slideshare.net 12
http://www.techgig.com 7
http://timesjobs.techgig.com 4
http://www.linkedin.com 2
http://www.lmodules.com 1
https://online.fvtc.edu 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Here is a transcript of the presentation:

    Okay folks, I think we'll get started. Web Accessibility: Principles, Strategies & Tactics.

    Sean Yo, BA & MA with a focus on digital media. Despite his youthful facade, he's been at the university twenty years.

    Works at subunit of web solutions, for many departments on campus. Has presented many times on accessibility. I give you Mr. Sean Yo.
    10:02 AM
    Sean: I started my undergrad in 1994, I'll leave the arithmetic as an exercise for the audience. Thank you, welcome. Last year I presented 'Real World Accessibility' where myself and Rob Geddes presented a case study on some sites we'd launched with our Web Solutions team. Was gratifying to receive the response, but also seemed that our expectations weren't quite as far behind as we thought. Had a lot of people asking us questions we thought we be assumed.
    10:03 AM
    We wanted to step back, practice what we preach, start off with fundamentals and not make so many assumptions.

    I'm a web analyst with a group on campus called Web Solutions, part of Computing & Communications Services. I'm an accessibility advocate - I chose that word, because it's not 'expert'. I think it's a challenge to lay down the gauntlet to be an expert.
    10:04 AM
    Before we get into it, I want to go over some fundamentals. Anyone here seen this abbreviation: A11Y, people who have drank beer with me don't get to answer.

    Randy...

    Randy: I've seen it, yes.

    Sean: That's awesome.

    A11Y stands for accessibility. Anyone know why?

    Number of characters. Me trying to use this abbreviation more. Good on Twitter.
    10:05 AM
    So to make sure we're on the same page, what is web accessibility? I like the Wikipedia definition, though it's a week and a half old. 'the practice of making websites usable by people of all abilities and disabilities. All users can have equal access to information and functionality'.

    Very strong, lots to work with, clearly centered on people.
    10:06 AM
    When we talk about disabilities, four categories: visual, hearing, motor and cognitive. Visual: blindness or low vision, contrast, colourblindness. Hearing: low hearing or deafness. Motor: physical issues, limited or fine motor control. Cognitive: learning disabilities, distractability, focus.

    Have to think about why are we doing this? I think our keynote speaker gave us some great information or ideas about why it's important.
    10:07 AM
    Following all coding best practices, XHTML/CSS, readable whitespace in your code. Pride in craft, but the purpose of a website is to communicate. Ignore accessibility and you're not communicating with a wide audience. Pay attention to website, better for everyone.
    10:08 AM
    Built environment: ramps are accessibility feature, but useful to anyone. Not going to spend a lot of time on the rationale, I'm going to assume most of us at an accessibility conference see the value. If you need more information, here are a couple of links and a high-level overview of the key points. Most important one is the first one, it's the right thing to do.

    Other two: saving resources and Google will love you.

    These slides will be up within minutes of the presentation, so don't worry about copious notes.
    10:09 AM
    So something before I get into the presentation, finish up with a small shift in my thinking lately. Last couple of years, if you read web design blogs and sites, you've noticed there's a new terms; UX for user experience. Usability, more people-centric, tied into specific experience. I like it, moves away from lab tests and checklists. Focus design on people.

    I've stopped talking about accessibility, trying to talk more about accessibility experience. It helps remind us and keeps us anchored on people. If there's one thing you take away today, accessibility is all about people.
    10:10 AM
    People have experiences, checklists don't. Not to say they aren't useful, I use them in accessibility testing and in my life. But they can give you false positive results on accessibility. Just like a spell-checker - they don't read.

    I thought I'd mention the recent discussion. Gary Barber designer in Australia, first slide in his Kill Accessibility presentation. He is an accessibility advocate, very passionate. Let me read you the core of his idea:
    10:11 AM
    Considering accessibility as a separate item is the wrong approach. Need to consider universal design. Forget about accessibility as a separate issue, we need to design for people using accessible technology just like any other issue.

    He's doing a good job of advocating and pushing discussion forward. I take a more moderate approach, instead of killing accessibility, talk about experience.
    10:12 AM
    Principles, where I'm going to talk about thinking about accessibility. Only one that matters: people first. Throw out the rest of my slides, if you keep this one you're doing okay.

    AODA lists some principles: independence, dignity, integration opportunity. I really like this, tightly centered around people.
    10:13 AM
    W3C POUR principles - has anyone heard of them? Every accessibility checker you've ever used, this is what drives it. Really good, but I prefer AODA ones, more human. These are about requirements and features. Perceivable, Operable, Understandable and Robust are absolutely important to accessibility work.

    Robust means cross-platform so you can come to it with whatever device you want.

    Any questions?
    10:14 AM
    Okay, so let's talk about strategies. We've moved from fundamentals, thinking about web accessibility, now talk about planning for accessibility from the beginning. Don't want it to be an afterthought, duct-taped or bolted on at the end. It's really expensive to do it that way.

    When you're in a project and you're wondering if you can drop the accessibility part, you're deferring and increasing the cost.
    10:15 AM
    The later software errors are removed, more expensive to take out. Anyone built any software is familiar with this. No accessibility is an error.

    Analysis, design, build, launch, support - software life cycle. The later you try to insert accessibility, the more expensive it'll be. Want to focus on the support piece - if you don't have accessibility built into the project, very real risk of it being a significant part of your support effort.

    Every change request after launch is going to get more and more expensive as it has the same life cycle.
    10:16 AM
    The idea there is to plan for accessibility at every step. Continuous and iterative design and testing.

    The takeaway from this is accessibility is not an option, but part of completing a website.
    10:17 AM
    So now I have a series of strategies to think about, and the first is avoid assumptions about your visitors. The most general, biggest bang for your buck. Issues creep up when you assume people will understand where to click, what colour means what. Stop making assumptions and just ensure you're providing it, that's when you're on the right path.

    If you're going to make one assumption, count on text. Text in, text out, everyone can handle it, maybe with an assistive technology.

    If you're not able to provide text, provide a text alternative.

    Don't take control of your visitors' experience. For something simple, don't play music in the background with a pop-up window remote control. You're taking control of that experience and making hard for the user to regain it.
    10:18 AM
    Automatic advancement to a new webpage, things like that. Let the user be in control. And also as a general note, never play music on a website!

    Use clear language - we can see that user experience and accessibility experience overlap. I think the idea that we shouldn't treat accessibility as a separate thing, I think that's a great idea, I wish we were there. I think there is that overlap already.
    10:19 AM
    Also true of making sure your website is usable, searchable and navigable. Very much the POUR principles by the W3C. Alternative methods to access your content, different users want access in different ways. Lots of people won't ever use your menus, just the search box.

    Be semantic. So when you code with HTML, when you use a table, use it for tabular data, not layout. Don't use a table to position information on the page. Use emphasis and strong tags, not bold or italics.
    10:20 AM
    The user can override emphasis and strong tags, screenreaders can interpret it. I don't think it's happening any more now, but in the past bold text in screenreaders increased the volume - it's not happening any more? Okay. Bold used to shout at people in the screenreader.

    Ensure you separate content and presentation. Make sure you're providing the text content, not inserting presentation information like page layout, style, colour - use stylesheets to capture all that separately.
    10:21 AM
    Progressive enhancement is the new graceful degradation. Not a radical shift. From a design point, start from a rich experience - if you don't have Flash use text, if you have IE just turn off the site!

    Extra things you provide progressively enhance the experience. Important shift in thinking.
    10:22 AM
    Testing is crucial to accessibility. This model comes from a training session with Derek Featherstone at the CNIB. Derek is going to be presenting, and I encourage you to go to that session. Also a training session on Thursday and we have a discounted rate for that. Fantastic deal, talk to your rock star accessibility guy.

    Four sections in this model: design, functional, demo and final. In the design testing, accessibility issues around layout, colour contrast - best time to unpack your assumptions, make sure you're not going down a path that's going to be expensive to back out of.
    10:23 AM
    Functional testing: test entire site with just a keyboard, should work easily. Ensure you're using linear flow throughout your site - order presented is the order coded.

    Assistive technologies are a prerequisite for accessibility, but aren't accessibility unto themselves. Working with them isn't enough. We need to go further than that.
    10:24 AM
    Demo testing - all alternative text in place, test with a screenreader, turn off CSS and just look at your site. Good, quick way to see how things go in terms of accessibility.

    If it becomes unintelligible when you turn off CSS, it's time to make a change.

    Final testing: test with real people. Hopefully you're able to test with people with different needs with assistive technologies.
    10:25 AM
    Ethnographic testing, a fancy word meaning test with real people. Build your network, find a company that offers a paid service with accessibility testing. Not enough to simply imagine. Imagining and empathy are the foundations, but won't get you the final mile. You need to make sure with a valid test that you've achieved your goals.

    Any questions? Yes.

    (question inaudible)
    10:26 AM
    So the question is based on text-in, text-out, what to do about Flash, which is sometimes used to display text.
    10:27 AM
    Inaccessible and hidden from screenreaders. What's the future of accessible Flash? I would hope the future is HTML5 and CSS3, by moving to that technology. Not as mature as Flash in the aesthetic experience, but the potential is there and there's a huge win by moving to that model. It's more open, easier to peek under the hood and see what's happening. It's also more searchable.

    You know, the Apple guys are here. They might want to talk to you about Flash!

    Question: What is the most efficient way (inaudible)
    10:28 AM
    Sean: Design step of accessibility testing, best practice, navigation, content, site purpose. Great candidates, no matter who user is, people have different opinions. Good linear flow, usable text, declaring early where you are, what you're doing here, why you want to be there. Skip to content links depending on how your page is laid out. Same way you want someone to quickly understand message on a billboard. Land on a page and understand within a few sections where I am and why I'm here.
    10:29 AM
    Skip to navigation, skip to content. Useful page titles are announced first, very long company name colon 'something your CMS generated' index - not very helpful.

    Descriptive and useful as possible. Great question, never be a perfect answer. That final testing point is where you'll get your answer, when you talk to real people with real needs, but always biased by people you talk to.
    10:30 AM
    Um, you know, I don't think I Have a really good answer for that one. I know when I make web - so the question is, what kind of behaviour should we have when we link out? New window, tab, same window?

    I don't know what the best practice is -

    So a comment we have here, to not open a new window so you don't break the Back button behaviour. Certainly as a general principle I try not to open a new window unless it's a reference link, like Wikipedia.
    10:31 AM
    That might not be the best way to do it, I'm just sharing. Anything else?

    Okay, so now we're looking at tactics, this is the doing accessibility.
    10:32 AM
    The founding idea here is if you think of the web experience as a stack with HTML bottom, CSS, middle, Javascript top, solve problems as low in the stack as possible. Easier to maintain, simpler solution, probably work, be more satisfactory. Javascript to solve problems - more complicated system. The further down that stack, more fundamental, more simple, more powerful.

    So for the tactics section, I'll look at three examples: images, forms, tables. These three things I'll be lining up reflecting on the principles and strategies we talked about.
    10:33 AM
    Accessibility of images: want to use alt tags for all images. If you have the ability in a CMS or similar authoring tool to enforce alt tags, that can be a good thing. Collaboration conversation is going to be more powerful than enforcement. Would rather have a conversation with people and get buy-in. If you just use compliance on that, you'll get blank, period, asdf, instead of simply looking for compliance and not achieving your objective, better to have a conversation with your developers.
    10:35 AM
    I love those tools, because I forget. There's a place for that. Using it as a compliance tool might have challenges, but you might have compliance regulations that make it an enforcement, no room for error on whether there's alt tags. Short descriptions, less than 100 characters, not always needed if you have a redundant image, or the word 'help' with an question mark icon, the question mark doesn't need a 'help' or the screenreader will say 'help help'. Amazon help page says 'help' 30 times in a row. Decorative images don't need alt tags.

    An alt tag that's set to null, alt= ' ' tells the screen reader to skip, no search engine penalty. Best to set it to null so the screenreader understands there's not supposed to be content there.
    10:36 AM
    On images, be careful with the meaning of colour. Using it to indicate information. It isn't evil, but when you provide non-text information, you need an alternative. If the only way you indicate a warning is yellow and an error is red, you need alternative, such as leading with 'Warning:' or 'Error:' Don't rely on it solely to communicate it. Some sighted people can't distinguish colours, too.
    10:37 AM
    Forms: the key tactic is to give forms linear flow. First to last in the order of the screen. It's possible to move things around in a form, make sure the submit button is the last item on the form as it's a signal the form is finished.

    If you want to place that before for screen users, place it with CSS. Tab index should only be needed if you're breaking linear flow, which you shouldn't have.
    10:38 AM
    And all these things are talking about separating content from presentation. Talking about tables - tables aren't evil, they got a bad rap when CSS came out, but people were doing bad things with tables. Using them for layout is a bad idea - using it for tabular data is a great idea. This is an example. Don't use it to shoehorn a form to the layout you're looking for, or an image map with image slices - don't let Photoshop build your website!

    Any questions? Dave?

    (question inaudible)
    10:39 AM
    I would say that I would not do that. I think that an argument - so one of the lovely things about semantic HTML - so the question is -
    10:40 AM
    About using forms and tables together, and is that a semantic case for a form being a table. When you talk about semantic HTML you're going to get an opinion on what is this tag for, what did the W3C mean. Better strategy is to use CSS positioning. Screenreaders give a lot of overhead about row, column announcing where you are. CSS is a cleaner experience.

    (question inaudible)

    I believe we'll also have audio, and I'm going to be working, and we have a transcription going on right now.

    (question inaudible)
    10:41 AM
    The comment is that when you code forms, ensure form controls are actual form controls and not calling out to link control, because that can be confusing and people lose their way.

    Anything else?
    10:43 AM
    Okay, so I want to talk about a few tools. JAWS is the de facto leader in screenreaders, it's a commercial product. Try the demo if you're working on web accessibility. If you've never tried navigating a page with a screenreader, you're in for a treat. It's really important to have that experience. A development team should have at least one copy of JAWS so there's an opportunity for early testing and maintaining that experience of using a screenreader, and so it's not a one-time thing. NVDA is an open-source screenreader, pretty good, some of the voices are a little rough. Commercial tools have more polished voices.

    NVDA can use Microsoft ISAPI drivers and they're quite an improvement over what ships with NVDA. Fangs is a plugin to Firefox, renders your page as a screenreader would see it in text. Flip a switch and see what the page 'looks' like to a screenreader.
    10:44 AM
    Firefox web development toolbar has great tools in it. I can't make a website without it any more, not without crying. Under the CSS menu there's a turn off CSS option, which gives you a great idea of what's happening. Also has convenient links to CSS, HTML and accessibility checkers. Fires you off to Cynthia, which I'll talk about.

    Firefox accessibility extension also a great toolkit, plug it in and check it out. I've got a time check so I'm moving on.
    10:45 AM
    A few services, accessibility checkers. To go back to People First, we don't want to see that things pass a checklist and think we're finished. But they're very useful and save you a lot of time. Wave WebAIM is very nice, very slick, good reports, easy to share, not overly technical.

    FAE is also very good, a new one to me, found it recently. Contentquality.com [http://Contentquality.com] is the Cynthia checker, I've used for a long time. I'm not going to be using it much, the other two are much better.
    10:46 AM
    Toddis.net [http://Toddis.net] at the bottom, is a Spanish site, you have to go to the English version. Very serious accessibility checker.

    Reason I include it, it presents its report against the POUR principles. Really useful and interesting. I haven't used it on a project, but I will definitely be taking a look at it as a real-world test drive.
    10:47 AM
    Books: these are the two I go to the most frequently. Dan Cedarholme's Web Standard Solutions; Design Accessible Websites by Jeremy Siddyck (sp).
    10:48 AM
    Before I take questions, I'm organizing an accessibility camp tonight. An 'unconference', which is a participant-driven event. We show up, do some introductions, decide what we're going to talk about and put up a schedule. Very dynamic, interactive, flatter than a conference. Here tonight at 7:00, if you go to a11ycamp.org [http://a11ycamp.org] you can register and I can get you a wireless account.

    I also registered allycamp.org [http://allycamp.org] and you can still get there! And you can show up without registering and I will welcome you and give you a cookie. I'm not joking, I really have cookies.

    But I'd really appreciate it if you register, it'll help give me a record of what's going on. It's not just for this conference, if things are wildly successful I'm hoping this website becomes a hub for other areas.
    10:49 AM
    (Question: Are the cookies homemade, or...?)

    Sean: They're being provided by Hospitality Services. So kind of both.

    Do we have time -

    Two more questions, not about cookies.

    Question: Two free tools to check colour contrast (inaudible)

    Colour Contrast Analyzer, check contrast & luminosity, download.
    10:50 AM
    Also Adobe Systems website, bit more complicated, recommend it for colour geeks. Much more extensive, little bit hidden.

    I'm available to talk, please come up to see me, I have cards and cookies!

    You have ten minutes to get to your next presentation, please fill out the evaluations that are in your packages.
    10:51 AM
    Go to seanyo.ca [http://seanyo.ca], there'll be a link to Slideshare in the next 5-10 minutes.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • A11y is anabbr for accessibility – a numeronymLike i18n for internationalization We’ll come back to this later…
  • VisualBlindness low vision color-blindnessHearingDeafnessMotorInability to use a mouse slow response time limited fine motor controlCognitiveLearning disabilities distractibility inability to remember or focus on large amounts of information
  • Making a web site accessible is work – but so is following all types of coding best practices like keeping presentation code in CSS, using HTML semantically, and using readable white space in your code There is the simple motivation of pride in craft…but more important the purpose of a web site is to communicate If you ignore accessibility, your website will be less successful When you pay attention to accessibility, in my experience, the whole website is better for everyone Let’s look to the built environment – ramps, powered doors and extra railings are an accessibility features – but they can potentially help anyone in that building
  • Makingaccessibile websites can be challenging – and we’ll all make mistakesChecklists are not a bad thing – they can be a useful toolHowever, if you rely solely on checklists – you will generate false positive reports that a site is accessibleChecklists are about as smart as a spellchecker – try and keep that in mind
  • “considering accessibility as a separate item is the wrong approach. We really need to be considering the ideals of universal design, in which everything is designed for everyone.   Let’s just for a minute forget about accessibility as a separate issue. We need to design and develop for people using AT just like we do for any other usability issue”
  • Perceivable - Information and interface must be presentable to users in ways they can perceive.This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)Operable - User interface components and navigation must be operable.This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)Understandable - Information and the operation of user interface must be understandable.This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)
  • Providing an Accessible Experience requires contintuous and iterative design and testing
  • This model comes from a training session I took with Derek Featherstone that was hosted at the CNIB as part of the Registered Graphic Designers of Ontario Access Ability Conference.
  • Short description to provide context Less than 100 charactersNot always neededRedundant Images (Help + “?” Icon)Decorative Images (Rounded corners)Alt=“” tells a screen reader to skip – there is no SEO penalty here, since we’re resolving a repetitionRemember – People First…not checklists
  • Be careful when you use colour to indicate informationUsing colour isn’t evil – but just like an alt tag for an image, when you provide non-text visual information, you need to provide the same information by an alternative methodIf the only way you distinguish an advisory message that is a friendly warning or a critical error is making the warning yellow and the error red, then you need to think about providing that information by an alternative method. Include the word “Warning” and “Error” at the beginning of the advisory messageAlso keep in mind that some sighted people can’t distinguish colours due to colour blindness
  • Forms should be coded from the first element to the last in the order they are provided on the screenIt is possible to move things around in a form – forms are little HTML black boxes with a big red button on itMake sure the submit button is the LAST item in the form – this is a signal to screen reading users that the form is finishedDon’t force a form into a table for the visual design of a form – that code will be very confusing to a screen readerTab Index should only be needed if you’re breaking linear flow – if you’ve coded your form with linear flow, you don’t need tab indexCSS positioning that doesn’t break linear flowSeparating content from presentation
  • Tables are for tabular data semantic

Web accessibility 2010 v2 Web accessibility 2010 v2 Presentation Transcript

  • Web Accessibility
    Principles Strategies &Tactics
    Sean Yo• University of Guelph • Web Solutions • CCS
    @seanyo• seanyo.ca • syo@uoguelph.ca
  • Web Analyst
    Accessibility Advocate
  • Introduction
    Fundamentals of Web Accessibility
  • Pop Quiz:
    What is A11y?
  • What is Web Accessibility?
  • Web accessibility refers to the practice of making websites usable by people of all abilities and disabilities. When sites are correctly designed developed and edited all users can have equal access to information and functionality.
    http://en.wikipedia.org/wiki/Web_accessibility
  • Visual
    Hearing
    Motor
    Cognitive
  • Why Web Accessibility?
    • Doing the Right Thing
    • Beneficial Standards
    • Save Internet Resources
    • Be Recognized
    • It’s the Law… Or it Will Be
    • Ease of Maintenance
    • More Aging Visitors
    • Care and Sleep Well
    • Google Will Love You
    http://accessites.org/why/
    http://www.webaim.org/intro/
  • User Experience
  • Accessibility Experience
  • People Have Experiences
    Checklists Don’t
  • http://manwithnoblog.com/2010/05/20/kill-accessibility/
  • Principles
    Thinking About Web Accessibility
  • The Only One That Matters
    People First
  • AODA Principles
    Independence
    Dignity
    Integration
    Equality of opportunity
  • W3C Principles
    Perceivable
    Operable
    Understandable
    Robust
  • Strategies
    Planning For Web Accessibility
  • Plan for Accessibility…
    …From the Beginning
  • Most errors are introduced during requirements analysis and design.
    The later they are removed, the most expensive it is to take them out.
    Boehm et al (1975): “Some Experience with Automated Aids to the Design of Large-Scale Reliable Software.”
  • Website Lifecycle
  • Support
  • Change Request Lifecycle
  • Plan for Accessibility…
    …at every step
  • Accessibility is not an option
    It is completing a website
  • Avoid Assumptions About Your Visitors
  • Count on Text
    Provide Text Alternatives
  • Don’t take control of your visitor’s experience
  • Use Clear Language
  • Be Usable, Searchable and Navigable
  • Be Semantic
  • Separate Content & Presentation
  • Progressive Enhancement
    Is the new
    Graceful Degredation
  • Accessibility Testing
    Design
    Functional
    Demo
    Final
  • Design Testing
    Layout
    Colour Contrast
    Unpack Assumptions
  • Functional Testing
    Must work with a keyboard…Easily
    Linear Flow
    Assistive Technology is a Pre-Req
  • Demo Testing
    All Alt Text in Place
    Test with Screen Reader
    Turn off CSS
  • Final Testing
    Real People
    Different Needs
    Assistive Technology
  • Ethnographic Testing
    Test with Real People
  • Tactics
    Doing Web Accessibility
  • Solve Problems Lower on the Web Stack
  • Images, Forms & Tables
    Oh My!
  • Images
    Forms
    Tables
  • People First
    Separate Content & Presentation
    Be Sematic
  • Alt Tags
  • The Meaning of Colour
  • Give Forms Linear Flow
  • Tables Aren’t Evil
  • Tools:
    Jaws, NVDA, Fangs
    Firefox WebDev Toolbar
    Firefox Accessibility Extension
  • Services:
    http://wave.webaim.org/
    http://fae.cita.uiuc.edu/
    http://www.contentquality.com/
    http://www.tawdis.net/ingles.html