Re: Combine 79, 78, and 74 SCs? (was Re: Mechanism Disclaimer)

Gregg wrote:
> but it doesn't say HOW the user will change it.   It is like saying to the builder — your house must stand no matter what the homeowner does to modify the structure after you they buy it. 

At the level of the SC it states what the content should enable (like keyboard access, like info & relationships). At the technique level we need to define how.


> You can do a lot to make a house modifiable but you can’t be charged with ensuring that it will stay functional no matter what the user does.

We aren't talking about anything, we're talking about changing fonts & color, which should be relatively straightforward, and the Stylish extension is pretty good for that.

The spacing one might be harder, especially in tightly-packed application screens. If we struggle with that one I could see it being separated, but lets try it for the working draft.


> how do we keep it from reading
> "The page much remain functional if the user changes x,y, or z   except if the user changes one of these in a way that makes the page unusable. "

As outlined in another thread ("Re: Mechanism" I think, sent a little while ago), the plan is to test sites extensively using the tools, and update the tools until we hit a wall only authors can solve. 

Out of that we should also have a good set of user-agent scripts or possibly an extension that could be used as a baseline. I don't think it will be a big issue for colors or font-family though, the author-side is not difficult, but there are a few things to remember.


> So you are suggesting moving [spacing] out of this SC and making the Linearize SC also support linearization with unknown spacings?

I think if spacing is problematic, we will either need to apply a limit (e.g. 0.5em around text) or move it out of this SC.

Linearisation is assuming the user completely overrides the layout (like the test page you tried), at which point spacing is not an issue because you have removed all the problematic layout code. 


> Maybe Adobe wants to or is releasing public PDF viewers that allow reflow

Acrobat reader (the free one) supports reflow (cntl-4 from memory) and changing the colours in preferences, has done for many years. It is only spacing that requires a more specialist client.

So we're ok there? (Caveat on spacing for now.)


> > If we have a known and important user-requirement that is not supported by some technologies (or rather user-agents for a technology), shouldn’t we make sure people understand that?  I’ve worked with many organisations that have relied on PDFs, and a simple analysis of their process and output *always* shows they cannot easily meet the accessibility criteria with PDFs. This is just another example.

> So you are saying that PDF can never meet WCAG? or can never easily meet WCAG?  or ?
not sure I understand you intent here.

You can create accessible PDFs, but the ways organisations work makes it more of a burden than using HTML. 
In-practice the difficulties of producing accessible PDFs at scale are leading organisations to move away from PDF as a primary content type. Even my bank does HTML statements as the primarily method!

At this stage (FPWD looming) I'm saying we should try.

Cheers,

-Alastair

Received on Tuesday, 24 January 2017 00:12:16 UTC