Day 69: How to Fail the Bare Minimum of Understandable and Robust
Today I'm concluding Level A conformance evaluation, looking at the Understandable and Robust principles of WCAG.
Things I accomplishedPermalink for "Things I accomplished"
- Read Understandable and Robust success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
- Mapped success criteria to failures of those criteria that I’ve encountered or read about.
What I learned todayPermalink for "What I learned today"
There are 5 bare minimum (Level A) success criteria recommended by W3C in order for websites to be understandable (readable, predictable). These success criteria are, as follows:
- 3.1.1 Language of Page
- 3.2.1 On focus
- 3.2.2 On input
- 3.3.1 Error identification
- 3.3.2 Labels or instructions
There are 2 bare minimum (Level A) success criteria recommended by W3C in order for websites to be robust (compatible for assistive tech and adaptive strategies). These success criteria are, as follows:
- 4.1.1 Parsing
- 4.1.2 Name, role, value
When these seven success criteria are met, it enables people of different abilities, no matter what aids they use, to understand and continue using your online content and services.
Examples that fail base conformancePermalink for "Examples that fail base conformance"
SC 3.1.1 Fail: A lang attribute is not present on the html element. The language of the web document needs to be explicitly defined for screen readers and browsers.
SC 3.2.1 Fail: Link opens a new tab. This should be avoided if not critical for the user because it can be disorienting to people of all abilities. I still see this a LOT for links, in particular, where no alternative of additional warning text is provided.
SC 3.2.2 Fail: Form submitted 'onchange' rather than allowing the user to submit the form when they were actually done. This impairs people from completing forms accurately and at their own pace.
SC 3.3.1 Fail: No descriptive error text was provided for required fields to help user know why their form was unable to submit.
SC 3.3.2 Fail: No label was associated with an input control by using 'for' and 'id'.
SC 4.1.1 Fail: I've recently run across a few of these failures! They usually come down to typos. For instance, if quotes or brackets aren't closed, or no space is left between attributes, it can create an incomplete picture for assistive technologies and browsers.
SC 4.1.2 Fail: No role, name, or state were provided on a custom component control with a div or span.
In conclusionPermalink for "In conclusion"
Though this evaluation was shorter, I recognized several things I knew to cause accessibility problems, but I didn't realize how bare minimum they were in this specification and how long they've been around (none are new in 2.1). I would be bold enough to say that all of these are easy failures to avoid and come at no real cost to the developer who knows what she's doing. Now, if you'll excuse me, I have a few bare minimum things to fix in my code this week...
Tomorrow I'll start looking at the next level up, which is a common goal for many organizations, including my own. I'll find out if we're meeting that goal or not!