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

Gregg C Vanderheiden
greggvan@umd.edu



> On Jan 23, 2017, at 4:37 AM, Alastair Campbell <acampbell@nomensa.com> wrote:
> 
> Gregg wrote:
>>  For example,  setting a Fixed page width in pixels defeats the natural reflow of text when you narrow the window. 
> 
> That’s very easy to override though, for example on this test page with a fixed width:
> https://alastairc.ac/tests/layouts/pixels.html 
> 
> Select one of the ‘linearise’ links under ‘Secondary content’.
> 
> That is a script you can run on (almost) any website, as a bookmarklet (drag/save it to your bookmarks). The Stylish extension some of the LVTF use can generally over-ride that as well, as could a user-stylesheet.

????  
are you talking bout the Author solving a problem created by the author?    
OK - that is what the SC would require so that would pass.

What the above example was supposed to be was an Author doing something to defeat a natural feature in the browser — and not also providing a solution.    Thus the need for the SC to be sure they didnt leave it there and also were required to fix it — as your example does. 

I don’t think it is fair to expect that most viewers would know now to create, install, or use bookmarklets.    Nor would they exist on public or shared machines.  



> 
> 
>> You can try to do it specifically by predicting what the author might do and writing a specific SC for that — but a better way is to say don’t do any thing that will overide access features… and then user failures to help identify specific things that would fail that SC so it is easier for authors to identify them. 
> 
> I agree, I think we’re both aiming for the same goal but coming at it from different directions ☺

Agree


> 
> 
>>> RE: "Adaptable presentation: Overriding the font-family, colors or spacing used on a web page does not cause loss of content or functionality."
> 
>> I dont think the author has any control of this.  You are asking the author to be responsible for what someone else does — without saying what that person might do.  
> 
> I don’t understand, it says exactly what the user might do: override three presentational aspects of the page. Also, the other phrasing makes a similar assumption but without leading to a true/false answer.

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.    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.    

If you use many different colors on your page — and the user changes the background color to be one of those colors — that information will visually disappear.   Do you need to include a script on every page that would detect changes in the background and readjust all the colors to maintain visibility of the content? 

> 
> 
>> For example — what if a person makes fonts very small (1 pt) or  the background is changed so that it is the same as the color of some of the text on the page.  
> 
> The font-size aspect is not addressed by this SC, only changing the font-family. 
> If the user changes the foreground colour without changing the background – that’s their problem the author did not block that. If they change foreground & background colors and then the site is unusable because it relied on background images to convey information, that is on the author. (The kind of issue that can come from high-contrast mode or similar browser plugins.)

Ah -  so what we really want to say is 

hmmm

Boy — I’m not sure how to word this that both embraces the fact that the author isnt responsible if the user does something that makes the page unusable - with a requirement that the page not become unusable when the user changes it —  without sounding circular.

in short - 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. "


> 
> The more difficult one (IMO) is spacing, which is much more likely to break layouts. Unless some fairly close limit is applied to that (e.g. 0.5em around text) it fits more towards the Linearize SC where you are assuming the user overrides layout.

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

hmmm

OK — they certainly interact with each other so may be good to combine.    

Have to think about that.    and if the problem doesnt just propagate to that SC.   But that might make sense since both are going to affect flow and layout.  

Very interesting. 


> 
> 
>>> Secondarily, do we really have to have all SCs including PDF (and Flash/Silverlight?) techniques? 
> 
>> IF you want technology agnostic SC — then you do.  
> 
> The requirement/SC is technology agnostic, and PDF can support it in theory. Isn’t this a case of PDF not being “accessibility supported”?

The definition of accessibility supported focuses on being compatible with AT and Access features.   

But if we are writing SC that would not permit use of PDF as it currently exists with the PDF public viewers that currently exist — that should be clearly stated.  

Maybe Adobe wants to or is releasing public PDF viewers that allow reflow — but if not  and no one else is doing public free viewers (or browser features or plug ins  — this SC could be a show stopper for adoption.

We need to understand this bit before moving forward.   I think




> 
> 
>>  If you are going to write Level A or AA techniques that cannot be met by any technology except HTML - then it may limit that adoption of the new guidelines. 
> 
> 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. 
More? 

> 
> Cheers,
> 
> -Alastair
>

Received on Monday, 23 January 2017 19:00:43 UTC