WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Chronicle of Higher Education article "Colleges Lock Out Blind Students Online" Chronicle Article and form control labeling

for

From: Gunderson, Jon R
Date: Dec 15, 2010 6:03AM

I am not forcing anyone to do anything.

People will review the data and make their own conclusions.

Hopefully good ones for improving accessibility and help open discussion at universities on how to manage and provide administrative controls for web accessibility, which seem to be sorely lacking.

Web accessibility is more than setting a policy and hoping developers do the right thing, it needs to be managed and audited just like other IT issues like security.

You either believe that you need to provide developers with coding practices or not for accessibility.

In my work with web developers I would do presentations on Section 508 or WCAG and many of them would come up to me after a presentation and tell me they understood some of the requirements and didn't understand mpost of the other requirements. Could I just tell them what to do and they would trust that I was providing them with coding practices that met the requirements.

The best practices are about what works for web developers and people with disabilities based on the current technologies and AT implementations (is a big factor in form control labeling)

Best Practices:
http://html.cita.illinois.edu

For the most part I have found developers have embraced the best practices since they make more sense to them than trying to understand the requirements of Section 508 or WCAG 2.0.

They also seem to make sense to a lot of other people outside Illinois because they have been independently implemented, even at less well known schools, like Missouri Sate University:
http://webaccessibility.cita.illinois.edu/data/school/204/

The best practices are based on web standards so developers gain the benefit of standards based designs.

Best Practices:
http://html.cita.illinois.edu

Since the best practices are based on web standards, many developers trying to follow web standards based design already found them on their own.

Doug Bergett of the University of Illinois was a earlier adopter of best practices at Illinois and helped in their development has a great quote:

"I learned best practices because of accessibility, but I use them because they are better web design"

This is the type of win-win situation we need to promote web accessibility,

if accessibility is thought of as a burden and not integral part of the design process, we will not get very far with web accessibility, especially in the Web 2.0 world around us.

If there are better coding practices for meeting Section 508 or WCAG 2.0 requirements I would love to hear about them, and I am sure other people on this list would also like to hear them too.

If you don't like these best practices I hope that it will spur discussion on your campus on what are best practices for your campus and I hope you will share the results with the rest of us.

Jon


On Dec 14, 2010, at 1:44 PM, John Foliot wrote:

> Gunderson, Jon R wrote:
>>
>> I find it interesting that people on this list were not outraged that
>> less than 30 percent of the 19,722 pages tested with form controls had
>> accessible labels.
>>
>> http://webaccessibility.cita.illinois.edu/data/
>
> The problem here of course is that this important data-point is lost
> amidst some of the other "Rules" that are circumspect at best, and
> outright false at worst. You take a mish-mash of important requirements
> and mix them in with a slew of imposed Best Practices that many disagree
> with - with a net result that you taint the good with the bad. Couple that
> with the hysterical reporting we see at the Chronicle of Higher Ed (fueled
> by your 'report') that focuses on *RANKING* rather than looking at where
> we have real problems across the board and the net result is that any good
> derived by your testing is off-set by that tabloid journalist approach.
>
> I will repeat the controversial Rules here and once again ask you to
> justify how failing to meet any of them results in inaccessible web
> content:
>
> *************
>
> HEADING STRUCTURE:
> "The page must contain at least one h1 element."
> According to whom? While it is certainly good practice to ensure
> each page has appropriate heading structure, nowhere (outside of the FAE
> tool) is it *MANDATED* as such - a page that lacks an <h1> is not
> intrinsically inaccessible. False data - False results!
>
> "The page should contain no more than two h1 elements."
> Please point to one national or international guideline or
> recommendation that mandates this. Another false positive from a
> mechanical tool, fueled by internal University of Illinois politics and
> policies.
>
> "The text content of each h1 element should match all or part of the title
> content."
> "Each h1 element should have text content exclusive of the alt text of any
> img elements it contains."
> Bull Feathers! Made up standards by a small team with an agenda to
> promote their internal tool - and it should be noted that failing to do
> either of these things in no way makes a page "less accessible" - it just
> doesn't meet their FAE Guidelines.
>
>
> DATA TABLES:
> "For each data table, the first cell in each column must be a th element,
> and each row must contain at least one th element."
> Patently FALSE! In fact, the table of school rankings at the
> Chronicle of Higher Ed that Jon points to in his earlier email
> (http://chronicle.com/article/BestWorst-College-Web/125642/) does not meet
> this "pass" criteria, yet is not "inaccessible" because of it - in fact
> the size of the table (183 rows in length with little-to-no internal
> navigation) is more of an access issue than the failure for each row to
> start with a <th>.
>
> The following table is perfectly acceptable and valid, and meets (as far
> as I know) all required accessibility guidelines as established by both
> the Section 508 Standard and W3C Guidelines (yet fails the FAE tool):
>
> <table>
> <tr>
> <td></td>
> <th scope="col">Sunday</th>
> <th scope="col">Monday</th>
> <th scope="col">Tuesday</th>
> <th scope="col">Wednesday</th>
> <th scope="col">Thursday</th>
> <th scope="col">Friday</th>
> <th scope="col">Saturday</th>
> </tr>
> <tr>
> <th scope="row">Week 1</th>
> <td></td>
> <td></td>
> <td>1</td>
> <td>2</td>
> <td>3</td>
> <td>4</td>
> <td>5</td>
> </tr>
>
> ...etc.
> </table>
>
> "Each th element in a complex data table must have an id attribute whose
> value is unique relative to all ids on the page."
> Please explain how failing to add an ID attribute to a table
> header makes it less accessible.
>
> "Each td element in a complex data table must have a headers attribute
> that references the id attributes of associated th elements."
> Please explain how failing to add a HEADER attribute to a table
> cell makes it less accessible.
>
> What defines "complex"? How does a mechanical tool makes this
> assessment? The table code example shown above is perfectly valid, is
> extremely accessible, and would fail 3 of the 5 data-table 'rules' this
> testing imposes on *your* sites. This is simply unacceptable.
>
>
> IMAGES/ALT TEXT
> "Each img element with width or height less than 8 pixels should be
> removed; CSS techniques should be used instead."
> Really? How exactly was this determined? If I have an image that
> is 9 pixels X 2 pixels than it should have alt text and not be moved to
> CSS?
>
> *************
>
> Until such time as clarification and proof exists to back up these claims,
> the entire exercise is mired in inaccuracies and confusion.
>
> Real Problems not evaluated in your testing:
>
> * Link text that is meaningful when taken out of context
> * Alt text that is meaningful
> * Ensuring that all information conveyed with color is also available
> without color
> * Appropriate foreground and background contrast
> * The ability to interact with a page without the need to use a mouse
> (tabbing)
> * The appropriate use of lists and list mark-up
> * Multi-media issues: no auto-start, caption/transcripts for video
> content, etc.
> * No blinking, no auto-redirect, no timing-out with prior notice, etc.
>
> I have also challenged you to clarify the fact that mechanical testing is
> but one aspect of accessibility evaluation on the 183 Report Cards you
> have issues at http://webaccessibility.cita.illinois.edu/data/schools/ so
> that we have a more accurate and truthful report to properly discuss at
> our institutions.
>
>
>>
>> I can't think of a more basic accessibility feature than using a label
>> element or title attribute to label a form control.
>>
>> The lack of form control labeling was my biggest conclusion from the
>> pages tested and my biggest worry is how to address this issue.
>
> Yet nowhere in your evaluations or reporting is this fact highlighted. Why
> is this?
>
>
>>
>> I think everyone agrees that form control labeling is a part of WCAG
>> 1.0, WCAG 2.0, Section 508 requirements and almost any other web
>> accessibility standard developed.
>>
>> If higher education can't even label simple form controls correctly,
>> how are they ever going to make Dynamic HTML widgets accessible?
>
> How about by focusing on real accessibility issues and not forcing
> everyone to 'pass' the FAE ranking exercise by insisting that every table
> cell have either a header or ID (when @scope is often more than enough),
> or that "The text content of each h1 element should match all or part of
> the title content"? Engaging in real dialog rather than perpetuating
> boogie-man scare tactics and tick-box evaluations that leave higher
> education institutions worrying about their 'ranking' rather than truly
> meeting the needs of disabled students within their student body.
>
>
> JF
> ===========================> John Foliot
>
> NOTE: These are my personal opinions, and in no way reflect the opinion of
> Stanford University (with whom I am under contract), T-Base Communications
> (my employer), my associates or other professional affiliates with whom I
> do business with.
>
> Co-chair - W3C HTML5 Accessibility Task Force (Media)
> http://www.w3.org/WAI/PF/HTML/wiki/Main_Page
>
> ===========================>