ࡱ> ! |dbjbj\\ 76g6gDP @0&&&8^D!t&($ 0(H0^001&+]D Xj$֓͑p11pp͑00Hjjjp00jpjjM0the0(m,`4}`J`ppjppppp͑͑R~ppp(pppp`pppppppppX h: Using the MSU Evaluation Protocol for WCAG 2.0 AA Overview We in the Digital Experience Team (DigitalX) of MSU Information Technology Services (ITS) are exploring mechanisms for improving the discovery and better enabling the resolution of accessibility issues in MSU websites and digital documents. The use of the accompanying  HYPERLINK "https://webaccess.msu.edu/_files/msu_evaluation_protocol.doc" MSU Evaluation Protocol for WCAG 2.0 AA (.doc), its  HYPERLINK "https://webaccess.msu.edu/_files/msu_evaluation_protocol_spreadsheet.xlsm" recording spreadsheet (.xlsx), and  HYPERLINK "https://webaccess.msu.edu/_files/msu_evaluation_protocol_instructions.doc" these instructions (.docx) (all at  HYPERLINK "https://webaccess.msu.edu/Help_and_Resources/evaluation-validation.html" webaccess.msu.edu/Help_and_Resources/evaluation-validation.html) is a step down that path. We are fully aware that it takes time to carefully evaluate digital material for accessibility but our strong belief is that over time it will become easier and easier both as issues are fixed and as the thinking about accessibility becomes a normal part of implementing anything in any digital document. With that in mind it should be obvious that the evaluator should not be a bad guy empowered to root out evil but it should always be the website or document developers and content creators that build the material that are reviewing their own, and their peers, work with open and honest eyes. This document is written to be used by developers and includes suggestions for developers to use to achieve the desired accessibility. The document, of course, can also be used by those tasked with testing only and they should feel free to suggest solutions to developers rather than stop at just flagging and noting a failure. In reviewing a digital document for accessibility, it is important to remember that the goal is inclusivity for all users. That inclusivity is met by meeting four principles: perceivable, operable, understandable, and robust.  HYPERLINK "https://www.w3.org/TR/WCAG20/" WCAG 2.0 (w3.org/TR/WCAG20) provides a large set of guidelines and explicit criteria (both passing and failing) that are intended to aid in meeting those principles. But be careful not to get lost in the details. From the  HYPERLINK "https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html" \l "introduction-fourprincs-head" WWW3 Introduction to Understanding WCAG 2.0: However, in WCAG 2.0, we only include those guidelines that address problems particular to people with disabilities. In other words, basic usability rules, best practices, and (robust) compliance with other web standards must still also be met. The primary goal is that everything in a document meet the goals and pass all applicable criteria then, only when some accessibility criteria cannot be met for something specific, that some alternative be obviously provided that gives as equal an experience as practical to users with specific disabilities for which the main content will not work. Certainly the above is a hard standard to always completely meet. And it gets worse. Any document that fails only one WCAG 2.0 AA criteria, allowing for alternatives to excuse some, fails to be WCAG 2.0 AA (the level MSU is aiming for) compliant and also, if the document is part of a website, the whole website fails. Perhaps the all or nothing  HYPERLINK "https://www.w3.org/TR/2008/REC-WCAG20-20081211/" \l "conformance-reqs" Conformance Requirements rules are draconian. Regardless, failing on a few criteria on a few pages is far far better than giving up and not making the effort to approach full compliance. It is in that light that the Appendices below (particularly  REF _Ref1982712 \h Appendix B Percentage or Strict Scoring) and the calculations in the spreadsheet provide both meaningful  REF _Ref503521802 \h \* MERGEFORMAT Percentage Scoring targets and, optionally,  REF _Ref503521980 \h \* MERGEFORMAT Strict Scoring of pass/fail. The law, of course, is strict pass/fail but binary 0/1 scoring makes it very hard to see or show progress when only very few items are still failing a specific Test in an otherwise compliant document or website. When going through the Tests below and comparing them to the discussion of their linked Success Criteria (SC) or other related resources also be aware that not everything is as cut and dried as the Tests might make it out to be. There is still a lot of controversy about some aspects of the Guidelines and it is very likely that some of the Guidelines will be modified in the future to improve meaningful access for all. Just as a for example, consider the one H1 heading per page rule of  REF _Ref504982144 \h Tier 1 Test 5 Heading Levels. You all know the rule that aint aint a word. Except, of course when aint is exactly the right word for the intended meaning. Hopefully! Heading levels, the example in hand, are kind of like that. This document, for instance has a title but only in the File > Info and, as currently being written at least, three Heading 1s, one for the main title of this document, and one for each of the appendices. Is it appropriate for appendices to have H1s if they are in the same document/web page? If, in this document, they were set to H2s the centering styling of H1 would not be applied but also they might get lost in the Navigation pane. If you have a web page with two main content blocks on it it too may deserve two H1 headings and maybe you should count it as a pass regardless. However, be very aware of what you are passing and what justifies that decision. Think What would I feel right about testifying before a judge or jury? if it came to that. So dont frustrate yourself by considering the Tests, Guidelines, or Success Criteria as absolutes, the only absolutes are simply given as perceivable, operable, understandable, and robust. For example, you might have an H1 News page but on it is a sidebar (HTML5