- From: Gregg C Vanderheiden <greggvan@umd.edu>
- Date: Sat, 21 Jan 2017 17:36:07 -0500
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-Id: <83A2D069-8082-4BC1-AB5E-60755F24BA44@umd.edu>
AH yes - I would agree If the SC had said “HTML Content etc….” then your comment would be correct. But it did not say the SC was limited to HTML or to Markup Languages. So it would have the effect of not allowing an author to use any technology that could not apply. If you want to restrict an SC to only apply to HTML or to markup languages — then you must include that constraint on application in the SC language — like was done with 4.1.1. So easy fix if that is your intent. Just put “HTML” in front of Content. Gregg C Vanderheiden greggvan@umd.edu > On Jan 21, 2017, at 5:01 PM, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > > Ø But not if not. I don’t think we want an SC at AA that can only be met with HTML or an expensive add on. > > Saying we can’t require something for HTML that can be done in HTML because other types of content don’t support it isn’t helpful. That’s like saying some buildings can’t have ramps built to the doors so no buildings have to have ramps built to the door. SC 4.1.1 was scoped to markup languages and this new SC could be scoped in such a way that it isn’t applicable when the presentation can’t be controlled. We shouldn’t hold back access on the most common form of web content. > > Jonathan > > Jonathan Avila > Chief Accessibility Officer > SSB BART Group > jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> > 703.637.8957 (Office) > > Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter <https://twitter.com/SSBBARTGroup> | Facebook <https://www.facebook.com/ssbbartgroup> | LinkedIn <https://www.linkedin.com/company/355266?trk=tyah> | Blog <http://www.ssbbartgroup.com/blog/> > See you at CSUN in March! <http://info.ssbbartgroup.com/CSUN-2017_Sessions.html> > > The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited. > > From: Gregg C Vanderheiden [mailto:greggvan@umd.edu] > Sent: Saturday, January 21, 2017 4:42 PM > To: Laura Carlson > Cc: Jim Allan; Dick; John Foliot; Alastair Campbell; David MacDonald; public-low-vision-a11y-tf; Patrick H. Lauke; GLWAI Guidelines WG org > Subject: Re: Combine 79, 78, and 74 SCs? (was Re: Mechanism Disclaimer) > > Thanks Laura, > > Very useful info. > > Question: > You said that > "It has been reported by Jim Allan and members of the Low Vision Task Force (LVTF) that Acrobat DC and VIP PDF Reader provide support.” > Are these available as browser plug ins? > If most browsers provide these as free plug ins — then you might consider this ‘supported by common browsers” thought normally we haven’t considered plug ins as browser support one could assume. > If they don’t act as plug ins — then you don’t have any browser support — so it would have to be AAA. (though I would love to have browser support and have it at AA !) > If these are not free - but expensive products - then I also don’t think an author could assume they would be in place on most user’s browsers. so.. > > Now if these capabilities could be a default feature in the default browsers (or maybe even if added as part of a free PDF reader install) then I can easily see this SC (and would love to see this SC) as AA. But not if not. I don’t think we want an SC at AA that can only be met with HTML or an expensive add on. > > Gregg > > PS ( are there any videos demonstrating how these products (Acrobat DC and VIP PDF Reader) allow adjustment of all the capabilities in the SC? ( i.e. Font, line spacing, word spacing etc) Love to see them. We are working (via OCAD) on a free tool that will do these for HTML. So would like to see these in action on PDF. Also always interested in anything in this domain. So badly needed. > > thanks > > G > > > Gregg C Vanderheiden > greggvan@umd.edu <mailto:greggvan@umd.edu> > > > > On Jan 21, 2017, at 2:51 PM, Laura Carlson <laura.lee.carlson@gmail.com <mailto:laura.lee.carlson@gmail.com>> wrote: > > Hi Gregg, > Thank you for your Email and questions. > It has been reported by Jim Allan and members of the Low Vision Task Force (LVTF) that Acrobat DC and VIP PDF Reader provide support. > The level is an open question and has been debated. We don't have consensus yet on that point. All 3 of the original SC levels were submitted at AA. Most commenters on Github would like AAA. At least one person from the LVTF stated it is a solid AA for many people. > There has been discussion in the LVTF to have an exception for UAs that do not provide support. Hence Wayne's mechanism disclaimer thread. > As for techniques Alastair is working on a solution ala his bookmarklet. Wayne has proposed: "Never use !important for online settings..." PDF techniques haven't been discussed. Perhaps Jim could add that to Thursday's LVTF agenda? > Thanks again. > Kindest regards, > Laura > On Jan 21, 2017 12:26 PM, "Gregg C Vanderheiden" <greggvan@umd.edu <mailto:greggvan@umd.edu>> wrote: > On Jan 21, 2017, Laura Carlson <laura.lee.carlson@gmail.com <mailto:laura.lee.carlson@gmail.com>> wrote: > "The presentation of content does not interfere with the user agent's ability to allow the user to change foreground and background colors, font family, or the spacing between characters, words, lines, or paragraphs to the element level, for the full range of values allowed by the user agent." > > > > > - This is an appropriate use of the word user - since is isn't about what a user can do - but what the user is allowed to do. > > > > - But I worry about the constraints here. What level was this going at? This would look to outlaw any use of PDF even though we have PDF techniques — since PDF doesn’t allow these things. > Also any other technology that does not have a CSS like markup. > > - is 2.1 moving to an HTML only web page approach? > > > - or does "for the full range of values allowed by the user agent.” mean that if the user agent can’t make these changes (e.g. for PDF) then the content passes without doing any of these things? > > > > - I see no problem with something like this at AAA but wouldn’t putting it at A or AA limit the application of 2.1 to HTML or markup languages. I might be wrong here - so this is a question rather than an assertion. > > > > - As before — Do you have sufficient techniques for meeting this SC with different technologies? That was one of the key tests we always used when creating a new SC in 2.0. That would clarify what this means and what is possible and which technologies can be used. > > Would there be a sufficient technique for this SC for PDF? > > > Gregg > > Gregg C Vanderheiden > greggvan@umd.edu <mailto:greggvan@umd.edu>
Received on Saturday, 21 January 2017 22:36:45 UTC