- From: Adam Powell <adam@adaminfinitum.com>
- Date: Mon, 3 Jul 2017 23:16:00 -0400
- To: WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <CALsiKnOODPNgxJxGexDbiv+QRZSvJrD91ObZwQm8nG-tjTh8ZQ@mail.gmail.com>
Hi All, I think I must be missing parts of this thread but a technique that might be useful is actually in use on the W3C website. The links have CSS styling rules of "text-decoration: none" (which prevents the default 'underline') and instead they use "border-bottom: 1px solid #color". By using this approach, it's possible to change the styling of the underline (on w3.org the border, darkens and thickens on hover) and therefore adjust padding/margins, appearance. If the links are in a document where the language ordinarily uses underlines, this could allow the underline to be offset and/or styled differently enough to be distinct. I hope that helps! Adam Powell http://www.adaminfinitum.com On Mon, Jul 3, 2017 at 9:27 PM, Andrew Cunningham <andj.cunningham@gmail.com > wrote: > Although it depends on language of the content. Underlining is often used > to indicate links. But when the language / script in question also uses > underlining as emphasis you can create confusion. Underlining by itself is > insufficient. It could be a link or an em element. > > Andrew > > > On Tuesday, 4 July 2017, Sailesh Panchang <sailesh.panchang@deque.com> > wrote: > >> HTML's default presentation has a purpose, accessibility being one of >> them. These help user groups other than with vision impairment. >> Links are underlined, contents of a TH cell in a table is bold and >> centred, a border around a set of form controls within a fieldset >> conveys a grouping relationship, the relative significance of >> headings with h1 ... h6 is discernible, the element that has keyboard >> focus is identifiable, and so forth. >> Browsers respect these too. >> Content authors should be free to replace the presentation styles in a >> manner that retains or enhances their effectiveness from an >> accessibility standpoint. >> Permitting them to tinker with the default presentation in a manner >> that impairs accessibility should be a violation. >> I am strongly in favor of an SC along the lines of the old Section >> 508 paragraph 1194.21 Para (b) Softtware Apps: >> >> • Applications shall not disrupt or disable activated features of >> other products that are identified as accessibility features, where >> those features are >> developed and documented according to industry standards. >> • Applications also shall not disrupt or disable activated features of >> any operating system that are identified as accessibility features >> where the application >> programming interface for those accessibility features has been >> documented by the manufacturer of the operating system and is >> available to the product >> developer. >> >> On the mobile platform for instance, I sometimes see that one is >> unable to use the handwriting feature to input text into a form within >> an application ... the developer has unknowningly done something that >> has broken the handwriting feature. (example of breaking a feature >> within the OS). >> (I had referenced the S508 paragraph in a CSUN presentation: >> http://www.mindoversight.com/csun/2016/slide8-0.html) >> >> Thanks and best wishes, >> On 7/3/17, Herin Hentry <herinhentry@gmail.com> wrote: >> > Hi Corey and Kiran, >> > >> > WCAG also mentions another failure. F73: Failure of Success Criterion >> 1.4.1 >> > due to creating links that are not visually evident without color >> vision. >> > >> > https://www.w3.org/TR/WCAG20-TECHS/F73.html >> > >> > There is also a note as Note: If the visual cue is only provided on >> hover, >> > it would still fail. >> > >> > Underline or Bold is the preferred visual clue. >> > >> > 2 techniques related to this are: >> > >> > - G182: Ensuring that additional visual cues are available when text >> > color differences are used to convey information >> > <https://www.w3.org/TR/WCAG20-TECHS/G182.html> >> > - G183: Using a contrast ratio of 3:1 with surrounding text and >> > providing additional visual cues on focus for links or controls where >> > color >> > alone is used to identify them >> > <https://www.w3.org/TR/WCAG20-TECHS/G183.html> >> > >> > Thanks to Patrick for the example link. It's a clear failure case. >> > >> > Thanks and Regards, >> > Herin >> > >> > On Mon, Jul 3, 2017 at 8:43 AM, Corey Collins <ccollins@usc.edu.au> >> wrote: >> > >> >> Hi Kiran >> >> >> >> >> >> >> >> My understanding, and I am happy to be corrected, is if you have >> >> sufficient contrast between your link colour and your background colour >> >> (Success Criterion 1.4.3 and 1.4.6), plus sufficient contrast between >> >> your >> >> body text and link text colour (3:1), you can provide a link with no >> >> underline as long as there is an additional differentiation (underline) >> >> when the link receives hover/focus. >> >> >> >> >> >> >> >> Further detail: G183: Using a contrast ratio of 3:1 with surrounding >> text >> >> and providing additional visual cues on focus for links or controls >> where >> >> color alone is used to identify them >> >> <https://www.w3.org/TR/WCAG20-TECHS/G183.html> >> >> >> >> Examples >> >> >> >> *Example 1: Colors that would provide 3:1 contrast with black words and >> >> 4.5:1 contrast with a white background* >> >> >> >> Refer to *Links with a 3:1 contrast ratio with surrounding text >> >> <https://www.w3.org/WAI/WCAG20/Techniques/working-examples/ >> G183/link-contrast.html>* >> >> >> >> >> >> >> >> If in doubt, the preferred technique is to use underlines for links. >> >> >> >> >> >> >> >> I’m not a fan of links with no underline in content but I have had an >> >> example at work, which I believe I could not fail and as a result, >> could >> >> not change the business owner’s decision. I’ll persist for a change >> >> anyway >> >> ☺ >> >> >> >> >> >> >> >> Hope that helps. >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> *Corey Collins* >> >> Web Accessibility Specialist >> >> >> >> Student Services and Engagement >> >> USC >> >> >> >> Ph +61 7 5456 5383 <+61%207%205456%205383> <+61%207%205456%205383> >> >> ccollins@usc.edu.au >> >> usc.edu.au <http://www.usc.edu.au/> >> >> >> >> University of the Sunshine Coast CRICOS Provider No. 01595D >> >> >> >> >> >> >> >> *From: *Kiran <kiranph@gmail.com> >> >> *Date: *Saturday, 1 July 2017 at 4:46 am >> >> *To: *w3c WAI List <w3c-wai-ig@w3.org> >> >> *Subject: *Are links should underline all the time? >> >> *Resent-From: *<w3c-wai-ig@w3.org> >> >> *Resent-Date: *Saturday, 1 July 2017 at 4:47 am >> >> >> >> >> >> >> >> Hey All, >> >> >> >> >> >> >> >> I need expert advice in learning and more clarifying the concept of >> WCAG >> >> 1.4.1 Link treatment. >> >> >> >> >> >> >> >> As per https://www.w3.org/TR/WCAG20-TECHS/F73.html , if links do not >> have >> >> underline or other visual cues will it be a failure? >> >> >> >> >> >> >> >> so If I have added a link in the paragraph where body text is black >> while >> >> the link within this paragraph is blue ( enough CCR), will that be a >> >> failure to WCAG 1.4.1 if I don't provide underline to this link? >> >> >> >> >> >> >> >> So does that mean, links should always be underlined in a paragraph or >> in >> >> a sentence? >> >> >> >> >> >> >> >> I was under the assumption that if links have a different color, plus >> it >> >> shows underline(or any visual clue) on hover/focus, should be okay and >> >> passes WCAG 1.4.1. >> >> >> >> >> >> >> >> https://www.w3.org/TR/WCAG20-TECHS/F73.html >> >> >> >> >> >> >> >> I appreciate your opinion in clearing my confusion on this. >> >> >> >> >> >> >> >> Thank you. >> >> >> >> USC, Locked Bag 4, Maroochydore DC, Queensland, 4558 Australia. >> >> CRICOS Provider No: 01595D >> >> Please consider the environment before printing this email. >> >> This email is confidential. If received in error, please delete it from >> >> your system. >> >> >> > >> >> >> -- >> Sailesh Panchang >> Principal Accessibility Consultant >> Deque Systems Inc >> Phone 703-225-0380 ext 105 <(703)%20225-0380> >> Mobile: 571-344-1765 <(571)%20344-1765> >> >> > > -- > Andrew Cunningham > andj.cunningham@gmail.com > >
Received on Tuesday, 4 July 2017 03:16:55 UTC