WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Available title indication via css

for

From: Chagnon | PubCom
Date: Nov 11, 2017 11:27AM

Love what Birkir said!
He so clearly defines the underlying issue. (I've repeated his post at the end.)

There are 4 stakeholder groups in accessibility:

1. The organizations that develop the standards, such as the WCAG, EPUB, and PDF/ U A committees.

2. The content creators who have to build their material to meet the standards.

3. The vendors who must create the tools to deliver and interpret the content per the standards. This group includes the vendors who make our content creation tools, such as Microsoft and Adobe; the vendors who create our delivery applications, such as our browsers and EPUB readers; and the vendors who create our A T and user agents.

4. The end user, which includes everyone whether they're using A T or not.

Personally, I'm a member of all 4 stakeholder groups, wearing 4 different hats every day.

The first group, the committees, are doing fantastic work.

The second group, content creators, are learning the ropes. More people today know how to make accessible content then 10 years ago, but this group will always be a work in progress. Kudos to those putting accessibility into their action plans.

The third group, all 3 types of vendors, haven't stepped up to the plate or haven't done enough. They are failing us.

And the reason is because we users have not forced them to keep their part of the accessibility deal. We have not held their feet to the fire, to the standards.

These companies are on the standards committees, so they know exactly what is required of their firms, their software, and their A T devices. But their companies do not implement the standards they help develop. The standards are ignored and, consequently, so too the people who depend upon those standards.

It's civil rights discrimination. Let's not forget that the most critical of these vendors are the largest, most profitable entities in the world. They can't cite financial hardship or lack of programming talent.

So don't water down the standards...well, unless an item really needs to be retooled or yanked, but think long and hard about removing items from standards. After a while, no one will trust your standard at all!

The weakest link of accessibility is the vendors--all of them. Stop buying their products. Stop using their apps. And tell them why you're doing this. Make your requests on their websites' wish list (search for "company name" + "wishlist") and tell them how their product is failing and what you'd like them to do.

And if a product, app, or service still doesn't meet the standards, then think about suing the company. Sometimes that's the only way the suits in the boardroom will get the message and direct their employees (and fund the R and D costs) to correct the shortcomings.

If you're with a government agency, school, or other large institutional, then tell the vendors you'll pull their software off your computer systems because it's not fully meeting accessibility requirements. Vote with your wallet.

Now, on the other side...

A shout out to Microsoft, Adobe, and Google...3 of the major product developers that affect our lives. Over the past couple of years, they have stepped up their commitment and work on accessibility. It's beginning to show in recent and forthcoming software versions.

An example: last week Adobe shipped the latest version of InDesign, the leading page layout program that is used to create nearly all of the textbooks, newspapers, periodicals, marketing materials, instruction and reference manuals, and books produced worldwide. InDesign is also central to creating EPUBs and other digital versions of these materials.

InDesign CS 2018 (a k a version 13) can now produce a near fully accessible PDF that is compliant with the PDF / U A-1 standard. Footnotes, anchored text frames, tables of content (and other lists), and more are all now "do-able" by the graphic designer. No -- or very little -- remediation is needed after the PDF is created.

Thank you to the team at Adobe that made this happen. (I know some are on this list.) It didn't happen overnight; development of InDesign's accessibility tools took about 7 years, with a huge push in the last 2.

Thank you.

For those who use InDesign, I'm teaching a 1 day workshop on accessible PDFs with InDesign on Tuesday at next week's AHG (accessing higher ground) conference in Westminster. There might still be some seats available.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists for Accessible Design and Publishing
print – digital – web – documents – pdfs – epubs
consulting – training – development – design – sec. 508 services
— — —

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, November 11, 2017 11:55 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Available title indication via css

There are two ways forward to resolve this problem in the longer term.
Either get the browser vendors to support the title ttribute properly, or drop it from the spec.
And, yes, if I use an HTML attribute properly, according to the definition of its use, it could be argued that it is not my problem if users cant perceive it )or at least it is not only my problem).

I can blame the browser vendors, or I can tell my keyboard only users to switch to Microsoft Edge, or file an issue with the browser they prefer.

I understand the dilemma, I feel it every day. Should I recommend not using a valid attribute, because I don't want to discriminate against my clients, but I also feel the pull of an achieveable, affordable universal access, which is that the authors cannot, and should not, go out of their way and not use semantically correct HTML because someone else in the chain is not doing their duty, whether it is the browser or the user agent.

I feel we keep dodging the real problem when we keep telling people they can't use the title attribute. The fundamental problem is, why can't they? Is it impossible for the browser vendors to support it? If so, it shouldn't be in the specification. Or is it that the vendors don't care, or don't put enough priority on this problem. Then we have to ask why, and how that can be changed.

I understand the pull, and the delicate balance we face, ultimately we need to make sure all our users can access our content. But in order to have a long-term success we also have to work on the standards or the user agents have to do their job.

Why does the standard allow the title attribute on non focusable elements? Isn't that a fundamental discrimination against people with disabilities in herent in the very specification behind web pages?
Yes, it shouldn't be used for essential information about an element, but if it is used by any information, and that information is not accessible to certain group of users, why is it valid use?
I don't pretend to have the answers, I admit that, but I think the question needs to be askked by now and together we may find those answers, not for today but for the future.