Presentation on theme: "WCAG 2.0 Compliance Costing Model"— Presentation transcript:
1 WCAG 2.0 Compliance Costing Model 16th Annual Accessing Higher GroundAccessible Media, Web and TechnologyConference November 4-8th, 2013Westminster, CoWhy this presentation?Phill Jenkins – IBM Research, Human Ability & Accessibility CenterDan Shire – IBM Interactive, IBM Canada3:30 – 4:30 PM Cotton Creek II6 November v6
2 Our agenda Project Overview I/T Web Project Life Cycle Sample sites & pagesTesting ResultsCosting ModelPolicy ConsiderationsOpportunities & ChallengesOur experience is relevant to organizations and web properties trying to estimate the costs of accessibility compliance.Why this presentation?
3 Project Overview Questions that need answers: What does it take to make a website accessible?What does it take to keep it that way?What are the opportunities and challenges?Project StepsIdentify candidate sites and sample pagesAssess (test) sample pages for accessibilityEstimate cost to test, repair, and maintainApply project experiences to sites and policy7 week timeline for initial project
4 I/T project life cycle (a simplified view!) User experience, including accessibility and support for inclusive design, should be at the heart of your project – and needs to be integrated into every phase of the project.Roles:Activities:Deliverables:Though we can use many models to describe a typical I/T project, this one provides an easy and generic set of phases: initiation and requirements, design, build, test and finally deploy/support.At the center of any information technology solution, we should have the users. We need to meet their fundamental business needs, or we cannot be successful.Within each of these project stages, there are critical roles (or participants), activities and work products or deliverables. Each of these items are affected by the accessibility requirements.
5 Initiation & Requirements I/T project life cycleUser experience, including accessibility and support for inclusive design, should be at the heart of your project – this can be integrated into every phase of the project.UsersInitiation & RequirementsDesignTestBuildDeploy/supportRoles:Business OwnerMarketingProject ManagerSolution ArchitectBusiness AnalystDesignerDeveloperTester/QATechnical writerActivities:Manage procurementDefine requirementsCreative DesignMacro and micro designDevelop applicationDefine & execute test plansDocument solutionSupport usersPlan for next cycleThough we can use many models to describe a typical I/T project, this one provides an easy and generic set of phases: initiation and requirements, design, build, test and finally deploy/support.At the center of any information technology solution, we should have the users. We need to meet their fundamental business needs, or we cannot be successful.Within each of these project stages, there are critical roles (or participants), activities and work products or deliverables. Each of these items are affected by the accessibility requirements.
6 Accessibility impacts by role Business Owner - correct policy (accessibility standards) and funding in placeMarketing – requirements, communications and awareness (i.e, launch)Project Manager – requirements, checklist, and project milestones and statusArchitect - enabled and capable technology designed into the solutionDesigner - design and implementation guidance complies with standardsDeveloper - coding implementation to comply with applicable standardsTester - QA and system testing to ensure compliance with applicable standardsTechnical writer – documents accessibility features, tutorials, etc.Policy and Funding
7 Web site refresh cycles Two factors to considerLook and feel (branding and navigation)Expensive to update – redesign and significant coding changes. If you get accessibility wrong, it can be broken everywhere.Content – e.g. seasonal hours of operation, ‘contact us’, online restaurant menu, new products and services.This information can be relatively dynamic and changes frequently.Compliance is a problem if the CMS is not enforcing the presentation styleHow often do organizations update their sites ?Consensus from 5 web developer agency interviewsStatic sites seem to be updated every 3 years, with a refresh of look & feel, navigation, menus, branding, and certainly refresh of content & technologyOur test sample (10 sites)Refresh periods varied over time. Anecdotal and a small sample.In the last 5 years, most sites appear to have been refreshed on a cycle of < 2 years.
8 Sites selected and description 99% of businesses1Company Size / Site complexity Small Medium LargeStatic web pagesA1 RestaurantA12 TownshipB1 InsuranceC1 Restaurant chainDynamicA2 Online magazineB2 University departmentC2 National RetailerC22 Government departmentE-commerceB3 Computer retailerC3 Automaker online storeA1: Small, private, staticA restaurant in a mid-sized town. It is a typical “pamphlet” style website, containing static pages with information on the menu and location.A12: Small, public, staticThe official website of a township. It offers static information about the town and council for residents and visitorsA2: Small, private, dynamicAn online lifestyle “magazine” offering articles, blogs and member-generated content.B1: Medium, private, staticA multi-office insurance company’s site offering information on products and services. Sections of site include role-based authentication. Content includes downloadable claim and administrative formsB2: Medium, public, dynamicA university department offering department-specific content presented through the university’s website branding and style. Includes course, faculty and department information, as well as a publications library.B3: Medium, private, e-commerceThe e-commerce site of a computer retailer with multiple outlets. Site content includes catalogue and full online transactions and well as user-based product rating and reviews.C1: Large, private, staticMulti-national restaurant chain’s informational site for Canada, featuring menus, location information, job opportunities and newsC2: Large, private, dynamicCanadian retailer’s web presence for everything from investor information to careers. Site offers different entry point for online shopping.C22: Large, public, dynamicProvincial government department offering online citizen services and applicationsC3: Large, private, e-commerceMulti-national automobile manufacturer’s online store for ordering a new car1 Source: Stats Canada
9 Most businesses are small businesses Canadian experience380,000 businessessmall and medium1 to 49 employees: 94.8 %50 to 200 employees: 4.2 %1 to 200 employees: 99.0 %large> 200 employees: 1.0 %
10 Site pages tested Small Medium Large Company Size / Site complexity Static web pagesA1: 5 of 8Homepage, Contact, About Us, Menu, PressA12: 5 of 154Homepage, Contact, Map, Community Events, News & AnnouncementsB1: 5 of 46Homepage, Forms, News, Contact, Sign InC1: 6 of 50Homepage, Location/hours, Nutrition calculator, Community, Card, FAQDynamicA2: 5 of 380Homepage, Registration, Search Results, Video Page, Blog PageB2: 6 of 126Homepage, Permission forms, Graduate studies list, Publications, CalendarC2: 7 of 107Homepage, Search results, Sign up, Locations, E-flyer signup, Weekly flyer, Sports, GolfC22: 5 of 14Homepage, Welcome, FAQ, Introduction, Step 1E-commerceB3: 4 of 1,434Create account, Product, Shopping Cart, Order Confirmation, (Third Party “Place Order”)C3: 5 of 201Build and Price, Choose Model, Choose Options, Choose Accessories, Summary
11 Testing methodologyThe assessment team performs the assessment tasks, collects, and summarizes the findings.Perform AssessmentScope & ScheduleValidate RequirementsDeliver and ReviewFindings &RecommendationsOptional UsabilityAssessment* Remediation* ImpactAnalysis& SizingPerform Assessment phaseCreate detailed application test casesConfigure automated test tools, AT, and OS settings1 Run test using automated test tools1 Conduct test using Assistive Technologies1 Conduct manual test using expert techniquesInventory and summarize findingsAssign severity ratings to issuesReview issues with technical stakeholdersThis diagram represents a summary level view of the overall process of doing an assessment.Assessment*RemediateLEGENDNote: 1Comprehensive testing methodology
12 Testing results – number of issues Company Size / Site complexity Small Medium LargeStatic web pages63 issues68 issues87 issues200 issuesDynamic248 issues85 issues32 issues160 issuesE-commerce48 issues28 issues1. The total number of issues does not reflect the relative effort to remediate issues. Some issues, such as using appropriate headings in content, are quite easy to resolve, while others, such as appropriately communicating errors in a form, are complex.2. The total does not always reflect the relative maturity of a site. The Medium E-Commerce site is very difficult to use but has one of the lowest issue totals. The Large Static site shows the second most issues, but only had one page that#. The total does not reflect the severity of various issues. Some issues will not prevent the site from being usable. (Failing to provide a means of skipping to the main content on a page makes the site harder but not impossible to use). Other issues, like the keyboard control becoming trapped on a page so a user cannot do anything, make a site unusable. Level A and AA issues are not separated out in this table.3. Conclusions about the nature of a category of site cannot be drawn from the sample size. While the two Small Static sites were quite closely aligned in regard to total errors, the two Large Dynamic sites’ issues varied by a magnitude of 5. A larger sampling size is required to make any accurate broad conclusions. The type of business (online versus bricks & mortar) can be a significant factor in the same quadrant. Similarly, there is not necessarily a correlation between the size of a company and the size of its website.4. The number of pages inspected varies by site, so the totals are not strictly comparable. Most sites have 5 sample pages, but others range from 4 to 7. With such a small sample size, one or two pages make a significant difference to the total issues captured, which can be misleading.Notes:Total number of issues does not reflect the relative effort to remediate issues.Total does not always reflect the relative maturity of a site.Total does not reflect the severity/impact of various issues.Total does not reflect the nature of a site’s category.Sample size may not be large enough to draw conclusions.Totals are not strictly comparable due to variance in number of pages assessed.
13 Testing results – types of issues & challenges Company Size / Site complexity Small Medium LargeStatic web pagesA1: identical ALTs, no keyboard, video ownershipA12: no keyboard, confusing; staff contentB1: Easy to understand, predictable, parsing errors, good attachmentsC1: Pretty good, except Nutrition table, parsing errorsDynamicA2: Advertising, “messy”, “accessible, just not usable”, parsing issuesB2: good text-based navigation; unreadable attachmentsC2: 900 Parsing errors, large but “pretty good”, minor structure issuesC22: Step 1 focus issue, by line navigationE-commerceB3: Horrible code, “busy”, 3rd party transactionC3: flash front end (not tested), On input errorA1A1’s failures as an accessible website stem from three main issues, which taken together create a “perfect storm” of inaccessibility.Its dependency on poorly constructed mouse-overs to provide navigationIts use of a table structure to control the visual presentation of its contentIts use of the same ALT description on every image, regardless of the image’s meaning or purpose.The mouse-overs are incorrectly coded, so cannot be activated by a keyboard. Because they are the sole means of navigating the site (a failure, in itself, of 2.4.5), it is impossible for a user without a mouse to go to a different page.A1’s layout is done by tables. This is not necessarily a problem, but the technique is outdated, and if done incorrectly (as here) can aggravate accessibility. Much of A1’s table structure is used to position images on the screen. But because each of these images and image fragments, is given the same ALT name (the site’s name), a user navigating with a screen reader hears the site name repeated almost a dozen times on every page before any other content is announced.If the ALTs were properly configured, the table would likely be treated as a layout table by assistive technologies, and not treated as a data table, containing useful information.A1 also raises an interesting question about who is responsible for accessible content. It contains three links to videos, but the videos, which lack captions and descriptions, are hosted on a separate site. Is A1 responsible for making this content accessible?Artifacts of old links left (tab stops with nothing there)Principle 1: Navigation controls that use text links instead of images will inevitably create less issues.A12Inaccessible navigation. Confusing orientation. Information architect failure ** UsableNot keyboard accessible. Main navigation is a script-based imitation of a link.No Home on the home drop-down. Forget how to navigate, even with mouseContent updatable by Staff (Events). Issue with training or upload tool?A2Advertising“Messy”Accessible, just not usableDesign versus information architecture. Site has “look” but no flowRedesigned about 2 years ago. Retrofitted content to new look?Good information on site, just not organizedParsing issuesBreadcrumbs could maybe help…B1Easy to understand content. Clear. Accessible downloadable content (out of scope)Predictable issues (e.g., a link to a doc in left nav)Parsing errorsALTS, but not criticalDemos how there are three components: HTML coding, accessibility and usabilityB2All attachments unreadable (out of scope)Used headers and content in usable tablesMinimized graphics so text-based navigation and standard elements are goodDespite HTML errors, the site is relatively usable “matter of degree”B3Parsing issues. Horrible code“extremely frustrating to use” Dead-ended at shopping cart verification. Couldn’t confirm** (3.3.4)“so much stuff” “I find it overwhelming”Visual info on the page not organized “busy”Jaws did not get focus. Dynamic updates? Check.** hard to handle keyboard focusC1M-L without nutrition calculatorNot very good markup, but pages not that bigDrop downs for navigation (keyboard access?)Lots of parsing errorsNutrition designed like a standalone app, but fails – drag & drop, flashGhost PDFs (also on Oscars)C2Parsing errors. 889 just on one page. Reduced to 10 with reviewHas link to accessibility page“other than the pages being large, pretty good”Some structure issues: multiple lists with no headings in between (likely result of items)“I was quite impressed with it”C22Main issue Step 1 focus –error 3.3.1? ** Check and report to PhillCould have made more use of headers, but layout not bad. Had to navigate by lineC3Flash no good otherwise quite good. Could follow steps in processPictures of modified car with no ALT (opportunity for long ALT?)**Had to arrow a lot due to info not separated with structureInclusive Design, Usable Access
14 Interactive – gives views by priority and technology WCAG 2.0 Success Criteria and Techniques4 Principles/ 12 Guidelines61 Success Criteria25 Level A13 Level AA23 Level AAAInteractive – gives views by priority and technologyHow to Meet4 Principles Guidelines Success Criteria (A + AA)100’s TechniquesPerceivable1.1 Text alternative1.2 Time-based media1.3 Adaptable1.4 DistinguishableOperable2.1 Keyboard Accessible2.2 Enough time2.3 Seizures2.4 NavigableUnderstandable3.1 Readable3.2 Predictable3.3 Input AssistanceRobust4.1 CompatibleUnderstanding WCAG 2.0Rationale and BenefitsExamplesSufficient TechniquesWCAG 2.0 TechniquesGeneral (G1-G199)HTML (H2-H91)CSS (C6-C63)SCRIPT (SCR1-37)SERVER (SVR1-4)SMIL (SM1-14)TEXT (T1-T3)ARIA (ARIA1-4)Common Failures (F1-F89)Core of the guidelines is at criteria and techniquesWCAG 2.0 has 25 Level A and an additional 13 Level AA for a total of 38 requirements.The 4 principles are for grouping.The 12 guidelines are similar to categories or functionalityThe 61 Success Criteria are equivalent to required checkpoints38 success criteria A & AA25 Level A13 Level AA23 Level AAASuccess Criteria = “What”Techniques = “How”Informative TechniquesGeneral and technology-specificTest procedures100s of techniques199 General91 HTML30 CSS37 Client-side scripting4 Server-side scripting89 Common failuresWCAG 2.0 challenges:Technical language and structureInconsistent granularitySeemingly inconsistent groupings of criteriaAddressed in template by attempting to:Create clear issue categoriesCreate one-to-one mapping of issues to criteriaUse natural languageBreakdown (or merge) criteria to arrive at usable dataOngoing process
16 25 Success Criteria (Level A) Costs of Web Accessibility remediation– Hours of effort by role (Level A)12 Guidelines25 Success Criteria (Level A)BizMktPMAchDevQATW1.1Text Alternative1.1.1Non-Text Content4 1*1All1.2Time-based Media1.2.1Audio-only and Video-only (Prerecorded)+ $ 2.25 / min1.2.2Captions (Prerecorded)+ $ 4.00 / min1.2.3Audio Descriptions or Captions (Prerecorded)1.3Adaptable1.3.1Info and Relationships281.3.2Meaningful Sequencenone1.3.3Sensory Characteristics1.4Distinguishable1.4.1Use of color.51.4.2Audio Control2.1Keyboard Accessible2.1.1Keyboard48/102.1.2No Keyboard Trap242.2Enough Time2.2.1Timing Adjustable2.2.2Pause, Stop, Hide1 site2.3Seizures2.3.1Three Flashes or Below Threshold.252.4Navigable2.4.1Bypass Blocks9/102.4.2Page Title.16/102.4.3Focus Order122/102.4.4Link Purpose3.1Readable3.1.1Language of Page3.2Predictable3.2.1On Focus3.2.2On Input4/103.3Input Assistance3.3.1Error Identification5Help, Tutorials3.3.2Labels or Instructions7/104.1Compatible4.1.1Parsing4.1.2Name, Role, ValueAll = all sites tested failed this criteriaNone = none of the pages tested exhibited this issue/failurex/10 = number of sites out of the 10 sites tested had this failureNotes: Example of variability by role - Text alternatives to images vs business alternative to CAPTCHA (i.e., phone support).Example of variability of applicable success criteria - Short text descriptions vs long descriptions vs CAPTCHA alternative.
17 13 Success Criteria (Level AA) Costs of Web Accessibility remediation– Hours of effort by role (Level AA)12 Guidelines13 Success Criteria (Level AA)BizMktPMAchDevQATW1.1Text AlternativeText alternatives1.2Time-based Media1.2.4Captions (Live)4*1none1.2.5Audio Description (Prerecorded)5/101.3Adaptable1.4Distinguishable1.4.3Contrast (4.5:1 minimum)634/101.4.4Resize text81.4.5Images of text21 site2.1KeyboardKeyboard Accessible2.2Enough Time2.3Seizures2.4Navigable2.4.5Multiple Ways3/102.4.6Headings and Labels2.4.7Focus visible2/103.1Readable3.1.2Language of Parts.53.2Predictable3.2.3Consistent Navigation3.2.4Consistent Identification3.3Input Assistance3.3.3Error Suggestion3.3.4Error Prevention (Legal, Financial)4.1CompatibleEmpty row or cell = no applicable level AA Success Criteria
18 Example rates by role Large ICT businesses Small ICT businesses $ Level 2 Business Owner$72 Level 1 Marketing$83 Level 1 Project Manager$ Level 1 Architect$ Level 1 Designer$83 Level 1 Developer$83 Level 1 Tester/QA$72 Level 1 Technical writerRates per day (7.25 hrs)ExperienceLevel 1 = 2-4 years,Level 2 = 4-9 years,Level 3 = 10+ years of experienceSmall ICT businessesRates approx. $40 to $10015 page sites range from$3k to $5kSurveyed 5 small businessesAssessed 10 sites
19 Preliminary survey – 5 web development teams A very small sample- 5 web development businesses (2 sole-proprietor, 3 teams (6, 20 , 60))Common themesSmall sites (< 10 pages) are still reasonable candidates for an HTML solutionMost sites are now implemented with a Content Management System (CMS)CMS allows the end client to maintain their own site contentEmerging support in CMS for accessibility standards (Drupal, WordPress)Some consultants have a proprietary CMS – this creates a dependencyNew sites?10 to 15 pages cost in the range of $3,000 to $5,000 – with an open-source CMSMunicipalities – publicly available information (newspaper article) – refresh the look and feel and the information architecture of 4 municipal web $57,000 with AODA (WCAG 2.0 AA) compliance - 8 years since last refreshKnowledge of accessibility and standardsGeneral awareness (5 of 5)Some consultants seem to have a good understanding (4 of 5 in this sample)
20 Sample Remediation costs Company Size / Site complexity Small Medium LargeStatic web pagesA1: $ 4.5k – $ 18.5k50 hours to 199 hoursA12: $ 4.8k - $ 16.4k53 hours to 184 hoursB1: $ 4.8k - $ 16k52 hours to 178 hoursC1: $ 12.4k - $ 32.3k134 hours to 349 hoursDynamicA2: $ 10.3k - $ 34k112 hours to 382 hoursB2: $ 4.5k - $ 21.2k50 hours to 247 hoursC2: $ 9.2k - $ 34.8100 hours to 385 hoursC22: $ 2k - $ 10k24 hours to 115 hoursE-commerceB3: $ 3.7k - $ 19.9k41 hours to 224 hoursC3: $ 2.4k - $ 13.5k27 hours to 152 hoursThe "Range" is provided to reflect the variability in the estimated effort to meet a particular success criteria. Due to dependencies on site design, site technology choices, and variance in the requirements themselves in WCAG 2.0 the range in estimating the effort varies - some success criteria with little to no variance, and a few others varying as much as 1 to 8 hours to remediate the type of issue. The range is displayed in detail in the cost model assumptions themselves and example discussed in the presentation.The costs reflect only the effort to fix the sample pages. The model includes sizings for all the type of issues to meet the 38 success criteria for WCAG 2.0 Level A and AA conformance, however, the occurrence of those issues is limited to those discovered in the selected pages. If the occurrence were higher and/or if there had been more variety of issues discovered, then the associated costs would have been reflected in the hours and costs depicted in the table. Since only 5 pages were tested, the costs do not reflect the total costs to remediate the entire site. For example, other parts of the Large e-Commerce (C3) were explored (not tested) and determined to contain Level AA issues not reflected in theses costs.The costs do not include QA/Testing and other costs outside the model framework (e.g., training).Only the costs for remediation that involves the roles of Business Analyst, Architects, Designers, Developers, and some time from Project Management were included in the sizings established to meet each success criteria. Other costs outside the model framework are discussed in the report.Conclusions about the costs to remediate other sites in the same category of site cannot be drawn from the sample size. While the two Small Static sites were quite closely aligned in regard to total errors, the two Large Dynamic sites’ issues varied by a magnitude of 5. A larger sampling size is required to make any accurate broad conclusions about the correlation between size of site and size of the company. The sample sites used in study do not necessarily represent the region – a valid sample size survey is needed. Costs for conformance to WCAG 2.0 Level A and AA are presented later in this document.Notes:Level A + AA costs for Business Analyst, Architect, Design, Development, & minimal Project Management (remediation costs did not include QA/Test).Costs above only to remediate 5 sample pages.Some remediation costs quickly exceed site redesign costs.Ranges reflect variability in site design, technology choices, and applicable accessibility requirements themselves.
21 Example of variability 3. 3 Example of variability Level A Provide labels - Labels and input instructionsSighted user sees the ‘Search’ buttonBlind user hears “Image Button 1”The following are examples of 1. how technology choices can have a great affect on the variability of costs to remediate accessibility 2. maintenance considerations 3. when to re-design 4. popularity of common user interface components in-house built open source vendor proprietary 5. Trends: today’s problems will not be tomorrow’s problems – so remediation and maintenance costs may not be accurate tomorrow.JAWS screen reader displays list of fieldsTechnology choice has greatest impact on variability of remediation costsMaintenance considerationsWhen technology changesIn-house custom built vs open source vs vendorTrends: Today’s technology may not be tomorrow’s problem
22 Example of variability 1. 4 Example of variability Level AA Resize Text - Non-HTML may not resizeFlash video playerNote the small blue icon in bottom right of video – see how it enlarges with zoom such that it is almost readable at 2X.Video content zooms - good,but player controls and labels don’t zoom - poorFix choice requires major re-work or major dependency
23 Site type and design impacts maintenance costs Company Size / Site complexity Small Medium LargeStatic web pagesPoor page structurePoor navigationPoor design/template affect whole (but small) siteLittle CMS usageAverage page structureUses CSS wellEasy NavigationPoor control labelsPoor keyboardDynamicDependency on inaccessible Non-HTML unique user interface componentsDocument repository accessibility will be large burden to maintain accessibility of all the documentsGood NavigationGood KeyboardGood Form labelsNeeds nested headingsE-commerceTransactions cannot be completed with keyboardDifficult to understandPoor form labelsFlash movies have no audio or text descriptionsNeeds long description of picturesWeb Site Summary:1. A1: This site is a low maturity; very poor page structure, poor navigation markup, poor text labeling and descriptions. This site cannot be navigated by a keyboard due to inaccessible Links and missing meaningful text on Images and Links.2. A12: This site is low maturity; poor navigation markup, poor page structure and text labels. This site cannot be navigated by a keyboard due to inaccessible Links and missing meaningful text on Images and Links.3. A2: This site is low maturity; poor layout, poor navigation markup. This site can be navigated with a keyboard, but requires page content structure with proper navigation markup, text description on Images, and alternate media format (audio/caption/text) on Flash movie clips. Also, Forms require proper text labels and HTML markup.4. B1: This site is a low maturity; Average page structure, average page navigation markup. OVERALL ASSESSMENT: Structured well using CSS as a layout tool. Otherwise, has no real accessibility features. This page can easily be navigated with a keyboard, and primarily contains downloadable content. Remediation requires meaningful text on Images and Links, and requires proper HTML coding.5. B2: This site is low maturity; Poor page structure, poor page markup, inaccessible documents. This site can be navigated with a keyboard, and primarily contains inaccessible downloadable content. Remediation requires proper page structure with Headers and navigation markup, and proper HTML coding.6. B3: This site is low maturity; Very poor page structure, very poor navigation markup, Very difficult to understand. This site can be navigated with a keyboard, but the shopping transaction cannot be completed with a keyboard. Remediation requires accessible keyboard controls, meaningful text labels on Forms, and proper page structure with nested Headers to make large pages understandable and easier to navigate.7. C1: This site is low maturity; poor page layout, poor navigation markup. This site can be navigated with a keyboard, but some pages have functions that lack accessible keyboard controls. Remediation requires proper page structure with nested Headers, and keyboard controls on mouse only actions.8. C2: This site is medium maturity; Lacks page structure and Landmarks, Good navigation Header markup. This site can be navigated with the keyboard, but tends to have large pages that are difficult to navigate. Remediation requires meaningful text on Forms and Images, and proper page structure of content sections.9. C22: This site is medium maturity; poor navigation markup and text labeling, good accessible Forms and accessibility help. This site can be navigated with a keyboard, and contains meaningful text for the most part. Remediation requires proper page structure with nested Headers.10. C3: This site is medium maturity; poor page structure and navigation markup, good accessibility to Forms. All Flash movies have no audio output, no text description, and no keyboard controls. This site can be navigated with a keyboard, but lack proper page structure with nested Headers. Remediation will require long descriptions for pictures, and alternate media (audio/caption/text) on Flash movie clipsNote: Example of maintenance impacts
24 Costs assumed outside model framework Technical and business IT costsProject level overhead costsOrganizational costsSoftware tools purchases and trainingAutomated tools like IBM Rational Policy Tester, a-Designer, etc.Tools costs still impact to business and out sourcing groupsOpportunity for government to provide automated tools to small business?Technical accessibility skills trainingArchitects, designers, developers, and testersAssume the skills and resources are availableCosts are still impactOpportunity for government to provide some training?Technology accessibility enabledNewer technologies and proprietary toolkits may not yet be enabledNewer technologies and proprietary toolkits may be better enabledAlternative or redundant solutions driving costs to 50% and beyond.Return on Investment (ROI) not factored into model frameworkIncreased sales, increased employee productivity, etc.Studies and pilots neededExample of alternative cost driver: early versions of FLASH and PDF, current 3D Internet like 2nd Life, Microsoft SharePoint without the HiSoft plug-ins, etc.
25 Costs assumed outside model framework – continued Project level overhead costsScheduleModel framework assume its part of an existing project - so no schedule delay/costs due to additional accessibility testing for example.Project overheadIt’s part of an existing project - so no additional costs for project management, regression testing, etc.Organizational/Enterprise costsUser Accommodations & supportCosts for ensuring that employees, citizens, and end users have a reasonable level of supporting assistive technology, internet access, latest enabled browsers, and a supporting operating system platform and the amount of training required to configure and use the technology efficiently – not included in model framework.Periodic AuditsQuarterly or Annual audits are recommend to better maintain compliance. Measurements (scanning & testing) and reporting (including executive dashboards) drives accessibility compliance for the organization / agency – not included in model framework.Application portfolio managementShould include accessibility and other attributes such as quality, privacy, security, internationalization, etc. - assumed are in place.Document ManagementAdditional costs depending on business/organization - assumed are in place.Costs are not zero!
26 Accessibility is less expensive when “built-in” Pre-existing site(add accessibility after site built)New/Re-design site(build-in accessibility before design)Accessibility Assessment(one time costs)[avoid these costs]Remediation efforts(one time costs)[avoid these costs]Training and education(periodic costs)=Training and education(periodic costs)Tools and integration(one-time & maintenance)=Tools and integration(one-time & maintenance)Project and Overhead(schedule and costs)=Project and Overhead(schedule and costs)Governance integration(one-time & maintenance)=Governance integration(one-time & maintenance)Quality Assurance(periodic costs)Remediation(less over time)=Quality Assurance(periodic costs)Remediation(less over time)
27 Accessibility costs LESS than NOT doing accessibility Building in accessibilityNot doing accessibilityTraining and education(periodic costs)Law suits(recurring costs*)Tools and integration(one-time & maintenance)Customer loyalty(recurring costs)Project and Overhead(schedule and costs)Reach less customers(lost revenue)Governance integration(one-time & maintenance)Search Optimization(recurring costs)Quality Assurance(periodic costs)Remediation(less over time)Adaptation for Mobile(recurring costs)Brand value(recurring costs)*lawyers are more expensive than web developers
28 Do most businesses have the internal skills to maintain their own web sites? In a word … no.87% of businesses have fewer than 20 employees (Statistics Canada 2009)Most of these organizations will not have an I/T person on staffThey would typically outsource their web site development and maintenance (based on interviews with 5 web development companies)If the site is implemented in an accessible CMS, content can be well-maintained locally (consistent, accessible, and following the rules)I/T and related technology based businesses may have internal skills available – (see report under IT capacity & skills)5.2 % of companies have 50 or more employeesReasonable to assume these companies may have I/T staff capable of developing and maintaining accessibility of the web site.
29 Canadian Accessibility Regulations Ontario: Accessibility for Ontarians with Disabilities Act (AODA)Covers BOTH public and private sector380,000 obligated organizationsCustomer service (like U.S. ADA)Information and communication (more than U.S. ADA & 508)All government (public sector) – WCAG 2.0 A now, AA laterBusinesses with > 50 employees must provide WCAG 2.0 (A, later AA) web sites for customersEmployment (like U.S. ADA)I/T must support employees with disabilities, or organization must provide reasonable accommodationGovernment of CanadaWCAG 2.0 A and AA for all federal departments & agencies
30 Policy Considerations Ownership of the problem / content – will require applicability guidanceContent vs hosting vs linksOwn content but not hosting environment (uncaptioned video on YouTube)Own hosting environment but not content (documents & web services from others)Own both (applicable) and/or links (not applicable)3rd party services and/or components/widgets (who and when in life cycle)Evolving technologies – will require updates to policyMobile apps (native & web), platforms, service providers, content owners, etc.HTML 5Conformance claims guidancePlatform: Which OS and browser to test? (Usage, ubiquity; which browser to recommend?)Testing tools: Which tools to use to make claims? (Cost, ease of use, supporting AA criteria)Assistive Technology: Which AT to make claims? (JAWS, ZoomText, AT failure, down level versions, etc.)
31 Identified challenges and recommendations Our project challenges reflect the realities to be faced by web site propertiesInsufficient testing tools, improving testing methods, uncertainty with guidelines, challenges with issue summarization, coordination of resourcesTraining - there’s a significant learning curve – WCAG standards are complex to learn and use.Universities – fundamental inclusive design curriculumUniversities – add accessibility to accreditationPractical & relevant training for web developersProfessional associations and certificationsTools – for development, testing, and reportingDifferent tools/approaches give different resultsRecommendations & support for tools, sponsor W3C WAIWork with vendors and open-source community (e.g. Drupal CMS)Processes – templatesA library of resources, especially helpful to small organizationsCollaborate with international partners on reusable assets (e.g. G3ict.org)I’m going to talk about challenges and opportunities arising out of the testing portion of the project. Dan will later talk about the same opportunities, as they relate to IT firms.The report contains quite a bit of information about the challenges the project faced. It may seem like I was looking for sympathy, but in fact, what I was intending to do was show how relevant our project experiences are to any organization faced with accessibility for the first time. The project requirements were a little unusual, and they lifted three experienced accessibility subject matter experts out of our standard way of doing things. It forced us to consider testing procedures and these guidelines in a way we hadn’t had to do in quite a while.We developed a testing template and checklist from scratch (appendix E). We compared a bunch of automated tools to see how each one broke (see . We puzzled over whether we were talking about the same issue when more than one of us flagged the same component on a page. We worked through how and possibly why the automated results failed to match our manual tests. We learnt from the experience, and we think the province as a whole, through the government, could benefit from that. Project challenges represent government opportunities.Our position is that the degree to which the province responds to the considerations we raise and provides a solution to the issues we flagged will determine the ease with which the site owners will meet the accessibility guidelines. Here are some things that could be done [ read slide: “standardize…”]1) Measuring ToolAdopt or create a tool for testing compliance. This would be the same tool that would be used by the government to audit compliance; therefore, a company would have a clear understanding of whether they had achieved the minimum goals of the province.a) The tool must be adaptable (e.g., government can modify the criteria it searches against -- necessary for a stepped implementation)b) and handle multiple streams (e.g., size of business determines entry point)HTML validator run first, then automated tool, then manual;Want to talk about the concept of Severity (David does 4 levels), and how it ties into a need to have a focus. You can’t just adopt the guidelines en masse. You have to decide which issues to tackle first – no difference then offering priorities based on experience and observations
32 SummaryRelevant to organizations and web properties estimating the costs.Considered all roles and activities in the IT project life cycle.Reviewed company sizes, web site complexities, anomalies.Reviewed accessibility testing methodology and results.Understanding Costing Model framework, costs, and variability.Skills availability and regulations.Policy Considerations.Challenges and Recommendations.
33 Questions? Phill Jenkins Senior Engineer & Business Development IBM Research, Human Ability & Accessibility CenterDan ShireIBM InteractiveGlobal Business Services, IBM CanadaIBM AccessibilityIBMAccess