ksux / ks-design-guide

Live pattern library for Kuali Student.
http://ksux.github.io/ks-design-guide/
9 stars 1 forks source link

Only interactive elements should have :focus, not warning messages #13

Open basham opened 10 years ago

basham commented 10 years ago

The following Skype chat discusses rational.

[12/2/13, 1:37:16 PM] Erik Rath: I have a question regarding https://jira.kuali.org/browse/KSENROLL-10939. It is suggesting that we remove the on-focus indicator for warning messages on Manage CO. However, since the user can put focus on the message, there should be some visual indication that the message is where the focus is (which is a requirement for WCAG 2.0 AA). I think we should close this JIRA as "will not fix", what do you all think? http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html

[12/2/13, 1:57:55 PM] Tara Noelle Bazler: so - I guess my take on this is that the W3C explanation of this standard is for actionable items on the page (for example, a field where you can enter text, buttons, links...) but the warning message is not an actionable component and therefore does not need to highlight.

[12/2/13, 1:57:59 PM] Tara Noelle Bazler: thoughts?

[12/2/13, 1:59:30 PM] Erik Rath: I think any item that can have focus benefits from having the focus clearly evident. Particulary in this situation: "People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located."

[12/2/13, 1:59:56 PM] Erik Rath: Or even for someone who leaves the tab and returns to it.

[12/2/13, 2:00:23 PM] Erik Rath: And ultimately, whatever visual design loss we have is less than the gain of the users knowing exactly where focus is on the page

[12/2/13, 2:06:38 PM] Tara Noelle Bazler: I guess what I'm not understanding is why the warning message would ever have focus since it is not actionable

[12/2/13, 2:13:23 PM] Erik Rath: There could be times where the message is a link

[12/2/13, 2:14:55 PM] Tara Noelle Bazler: I can see having focus for the link within a message, but not the message itself. from what I see, the focus is only actionable items

[12/2/13, 2:15:25 PM] Chris Basham: Everything that I read is indicating that focus should be reserved for interactive elements. http://webaim.org/techniques/keyboard/

[12/2/13, 2:18:57 PM] Tara Noelle Bazler: My concern here is that we take a standard too far and then don't know where to draw the line - for example, if the user clicks on other sections of text, would that also bring 'focus' to that paragraph/section? where is the cut off on what makes sense if we deviate from actionable items?

[12/2/13, 2:21:49 PM] Erik Rath: I think it makes sense to have all elements that can have focus, have some indication of focus. However, I suspect the issue is that ideally, if the message was text and not a link, it should not get focus, right?

[12/2/13, 2:22:17 PM] Tara Noelle Bazler: yes - if it is just a text message - no focus needed.

[12/2/13, 2:22:28 PM] Tara Noelle Bazler: if it is a link or actionable item - then give it focus

[12/2/13, 2:23:17 PM] Tara Noelle Bazler: but just give the link focus - not the entire message box

[12/2/13, 2:26:28 PM] Erik Rath: On 12/2/13, at 11:23 AM, Tara Noelle Bazler wrote:

but just give the link focus - not the entire message box

I think that is how it works now.

[12/2/13, 2:27:08 PM] Erik Rath: I will talk to Glenn to see if that is something that can be done on our end or if it should be a KRAD solution. Thanks for the input!

[12/2/13, 2:28:38 PM] Tara Noelle Bazler: thanks Erik

[12/2/13, 3:24:19 PM] Erik Rath: It looks like configuring warning messages to tab-stop only on links is something that would require KRAD intervention. That being the case, I think we should make a feature request to the RICE team for that configuration. In the short term, while the message is still a tab-stop, we should retain the outline, so the users will always know that the focus is on that element, even if they can't act on it. What do you think?

[12/2/13, 3:31:45 PM] Tara Noelle Bazler: I definitely agree that the feature request must be made. in the mean time, can the focus outline be configured to only show (for the whole box) when a link is contained in it? or is that also an issue?

[12/2/13, 3:32:40 PM] Erik Rath: I think we could do that, but do we really want to have tab stops that are invisible to the user?

[12/2/13, 3:34:07 PM] Tara Noelle Bazler: does it need to be a tab stop if there is not a link?

[12/2/13, 3:35:15 PM] Erik Rath: Yeah, it will always be a tab stop, which is what causes the outline to show up now. There doesn't seem to be any way to override that aside from (potentially) a change at the KRAD level

[12/2/13, 3:38:47 PM] Tara Noelle Bazler: then it seems we should ask for that change, too - unless there is some reason that a message area needs to be a tab stop (which I can't come up with a scenario that makes that make any sense). A highlighted message in and of itself is not an actionable item and shouldn't be set up to be a tab stop. a message could contain a tab stop in the form of a link or button - and that would make sense. So - unless there is some reason that I'm not seeing/aware of - it needs to change.

[12/2/13, 3:40:09 PM] Erik Rath: Do you agree that so long as it remains a tab stop (i.e. until KRAD fixes that issue), we should keep the highlight as a means of orientation?

[12/2/13, 3:40:54 PM] Tara Noelle Bazler: yes - while a tab stop - I grudgingly agree

[12/2/13, 3:41:00 PM] Erik Rath: :)

[12/2/13, 3:41:04 PM] Tara Noelle Bazler: :)

[12/3/13, 8:57:52 AM] Oliver Ng: Erik. Yes that was the idea behind that bug - messages should only have a focus state when there are action items contained in it