- From: Margaret Rasor <margaret.rasor@gmail.com>
- Date: Tue, 28 May 2019 18:40:19 -0400
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: w3c-wai-ig@w3.org
- Message-ID: <CAEnAyd0rDwrqamt+Fq8k5pLRDd6+-Ouw1R538_zOVN2q9Kr+gg@mail.gmail.com>
I'd like to contribute a little to this, I tested a UI design that is using links as sortable column headers. They look like links, and are actual links when I tried the hand test, but behave like sort buttons. When using JAWS they are called out as links, and the Value attribute does include the sort order. However, I failed it under 4.1.2 for incorrect Role, although initially I had thought it would fail 1.3.1 but after rereading the standard, I concluded what Patrick said. It seems to me that 1.3.1 is more about labeling fillable forms than Name, Role and State attributes of UI elements. Thanks, Margaret Rasor Section 508 SME & Tester CNSI 2277 Research Blvd. Rockville, MD, 20850 On Tue, May 28, 2019, 4:56 PM Patrick H. Lauke <redux@splintered.co.uk> wrote: > On 28/05/2019 21:07, Bristow, Alan wrote: > > > Links styled to look like buttons o_O > > > > Is there anywhere in WCAG where this practice is defined as > acceptable/poor/fail? > > No, not really. Highlighting links visually as "call to action" type > important links is fairly common, and is commonly understood by users. > > > In 'Resilient web design', https://resilientwebdesign.com/ Jeremy Keith > talks about 'material honesty'. > > > > The styling of A tags so they end up looking like BUTTONs must be one of > the most common failures of this. > > > > In the past I have considered 1.3.1: > > " > > Information, structure, and relationships conveyed through presentation > can be programmatically determined or are available in text. > > -WCAG 1.3.1 Info and Relationships > > " > > noting that what is visually a 'button' and so semantically should be a > BUTTON tag, when programmatically determined (by AT) is found to be an A > tag, so breaking WCAG 1.3.1. > > I'd say that's stretching it a bit... > > Also, from anecdotal evidence over the years, I feel confident in saying > that "normal" (not web developer) users have no idea what the difference > between a button or a link is. It's "something they click/activate" that > either does something or takes them somewhere. As long as it's > internally consistent within the site, and as long as it behaves as > expected, it makes little difference to users what's under the hood. > > There is certainly a problem when something that should act/behave like > a real button (like a submit button) is coded as a link - for instance, > it makes little sense for a "Submit" button on a form to be a link, as > users may (accidentally or not) middle-click it and it would open in a > new tab/window and not work correctly. These are the sorts of real-world > problems that would fail (generally, I'd class these under 4.1.2 for a > role mismatch at least, and advise to use an actual <button> or <input > type="submit">, or at least role="button" and adding extra JS to > suppress any link-style behaviour and add button/input type behaviour > like responding to SPACE). > > P > -- > Patrick H. Lauke > > www.splintered.co.uk | https://github.com/patrickhlauke > http://flickr.com/photos/redux/ | http://redux.deviantart.com > twitter: @patrick_h_lauke | skype: patrick_h_lauke > > >
Received on Tuesday, 28 May 2019 22:45:07 UTC