Re: Mechanism Disclaimer

Dont see my last +1 on the list - but I like this also.

> Patrick H. Lauke <mailto:redux@splintered.co.uk>
> 20 January 2017 at 11:32
> On 20/01/2017 11:00, Alastair Campbell wrote:
> It would help if we could build in the assumption that it is allowing
> the user to achieve something, for example:
>
> “Changing the font-family used on a web page does not cause loss of
> content or functionality.”
>
>
>
> Techniques for that will include things like not relying on font-icons
> to convey important information.
>
> Agree, this seems to more appropriately convey the desired end result. 
> (though now I'm wondering what the relationship to, say, native apps 
> would be, where the OS likely doesn't provide mechanism, and authors 
> WOULD have to code something up themselves - or were these exempt even 
> in the current wording?)
>
> P
> Alastair Campbell <mailto:acampbell@nomensa.com>
> 20 January 2017 at 11:00
>
> Josh asked:
>
> > Is there a worry within the LVTF that font-family and related CSS 
> type or code level changes may not be perceived as a 'mechanism' - and 
> therefore is not sufficient to satisfy some proposed new SCs?
>
> It is that the ‘mechanism’ language implies authors should create it. 
> If you look through font-family, linearise, spacing, & colors; almost 
> everyone assumes that is the case.
>
> It would help if we could build in the assumption that it is allowing 
> the user to achieve something, for example:
>
> “Changing the font-family used on a web page does not cause loss of 
> content or functionality.”
>
> Techniques for that will include things like not relying on font-icons 
> to convey important information.
>
> Cheers,
>
> -Alastair
>
> Joshue O Connor <mailto:josh@interaccess.ie>
> 20 January 2017 at 09:48
> Hi all,
>
> I've a question related to yesterdays discussion (but keeping it short 
> per Waynes request). Is there a worry within the LVTF that font-family 
> and related CSS type or code level changes may not be perceived as a 
> 'mechanism' - and therefore is not sufficient to satisfy some proposed 
> new SCs?
>
> Thanks
>
> Josh
>
>
> Alastair Campbell <mailto:acampbell@nomensa.com>
> 20 January 2017 at 00:26
> Hi Wayne,
>
> I'm not so concerned with whether the user can change the font-family, 
> as they can.
>
> It is what issues *come from* changing the font-family that are the 
> problem. I assume it is things like overlap, wrapping that breaks 
> interactive controls, and font-icons disappearing?
>
> Perhaps it should be something like:
> "Changing the font-family used to display a web page does not cause 
> loss of content or functionality."
>
> Anyway, it's past midnight here, g'night!
>
> -Alastair
>
>
>
> Wayne Dick <mailto:wayneedick@gmail.com>
> 19 January 2017 at 22:16
> I am proposing the following change to Font, Issue 79
>
> Only look at the disclaimer, but factor in Font-Family as a 
> 'mechanism' disclaimer. Is it too general? Should we have disclaimers 
> at all and insist developers code access? Would you prefer, a 
> mechanism exists, followed by the disclaimer?
>
> SC: Font
>
> "The user can change the font family down to the element level, to any 
> font family available to the user agent with the following exception.
>
> *If no mechanism exists to change font family on any user agent for 
> the target technology, then the author has no responsible to create 
> one. *"
> *
> *
> *
> *
> Bold added to emphasize the disclaimer language in question.
>
> I would appreciate help. Please keep your answers as short as 
> possible. There are no effective mail clients or assistive 
> technologies that support readers with macular damage. So, I have 
> serious difficulty reading threads.
>
> Thank You,
> Wayne
>
>
>
>

-- 
Joshue O Connor
Director | InterAccess.ie