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

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.


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

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


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


> > 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”?


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

-Alastair

Received on Monday, 23 January 2017 09:37:51 UTC