Modal window usage and styling

[benguhin]

Modals are super-helpful for focusing a user's attention on something when there's already a lot going on (e.g., within a complex form or web application). Sometimes this is so that they can read a page's Privacy Notice, or to warn against deleting their account, or to alert + enable them to Log In when they try to perform a specific action.

Here are some of our current styles:

I think there's a solid standard in combining the last two (the desktop version of the Paying For College modal + the mobile version of the complaint form modal)

[mebates]

I'm interested to hear the cf-gov refresh team's thoughts on modals. In critique last week, Lee was making a case against them because of challenges presented on mobile.

[himedlooff]

Mikes thoughts, not necessarily cfgov-refresh thoughts:

Creating another smaller scrollable window on an already small screen isn't a great experience to me. One big annoyance is that scrollable divs on slightly older android and ios devices won't scroll the same way as windows scroll. It scrolls with no momentum which is frustrating and annoying. You can add native momentum scrolling in newer devices with a css property which is good, yay!

Also with scrollable windows inside of a small touch screen window copying and pasting gets super annoying.

One other observation: when you have a modal that you have to scroll then maybe it's worth putting it on another page which would allow you to avoid the issues described above. In Ben's scenario maybe have a multi-page form with the privacy stuff on its own page? (Disclaimer: this might not be possible in your situation, and maybe you have reasons why multi-page forms are more harmful than the modal issues I described above. If so let's share so we can use our collective research to figure out a solid approach.)

[benguhin]

Yeah those are good usecases for when things get tricky. We can probably replace the Privacy and OMB modals on our complaint forms with some sort of show/hide functionality, but I think a modal makes more sense if we can make it work well. Linking to an additional page would take the user out of the form, which is not ideal :)

One thing to note is that it doesn't need to look like a traditional "pop-up" with the rest of the page frozen and partially blacked out behind it (i.e., it could actually be full-width on touchscreens). Not sure if that helps.

In any case I totally agree that we should combine our research to try to solve this! And collecting older phones to test on. Are there other problems to address in addition to scrolling within scrolling and copy/paste?

[himedlooff]

@benguhin I meant make it a step in a multi-page form, for example page 1 of the form is whatever, click "next", then you're at a page where you have to read/accept the privacy policy, you read it and check "i agree", then click "next" to get to the final step.

[benguhin]

Ah yeah that makes more sense. Tricky thing is that it's not actually a "step" on desktop so it's kinda weird to make it one on mobile. That's just one example, though - where else are we using modals now?

[himedlooff]

Yeah, I'd say think of the mobile scenario first, if breaking it up into steps makes the page less overwhelming then maybe that's a good thing to do. I don't see why it can't be broken up into steps for larger screens as well. Or you could use some ajax on larger screens to make a longer page with less steps (or one).

[stephanieosan]

Are we still trying to solve a larger modal design and policy issue here? Did any decisions get made or any solutions implemented?

[marteki]

Audit of found modals (includes some of the ones shown upthread)

Submit a Complaint (non-responsive pages)

https://help.consumerfinance.gov/app/payday/ask/p_id/249#currentPage=0

OMB control number. Short, includes a link to an email address. Gray overlay on screen, beam border, white background, dark text, close X link in upper right.

Privacy act statement. Longer. No next actions beyond the close button in the top right.

Both of the OMB control number and privacy act modals are triggered by a link in the footer:

Explanation of complaint narrative consent and publication process. Very long. Includes a link to a PDF.

This modal is triggered by a "Learn how it works" link in the form content:

Warning about form expiration. Short. Button to take action (kind of). Close link to dismiss modal instead of top corner X (though dismissal is possibly an odd task for this use case). Gray overlay background is a different opacity than others used on Submit a Complaint tool.

This modal is triggered by the form being open for a certain amount of time, and is not prompted by user interaction. 

Consumer Response Analytics Search

(internal site)

Export search. Short. Contains form fields. Button to take action. Cancel link near button to dismiss modal. Green stroke along top of modal. Gray area near the bottom for next actions.

Save search. Same specs as above.

Both of these modals are triggered by either buttons or links (not sure what the project team classifies them as) right under the header:

Paying for College - Compare financial aid tool

http://www.consumerfinance.gov/paying-for-college/compare-financial-aid-and-college-cost/

Save your work. Contains form fields. Button to take action, which triggers a system alert for confirmation. Small minicon in top right corner to dismiss modal. Super thin green stroke along top of modal. Dark dark gray overlay background. Not responsive.

Triggered by a button near the top of the tool:

HMDA

http://www.consumerfinance.gov/hmda/#video

Clicking on a "What is HMDA" link with icon right under the header...

...leads to a full screen video modal:

Is this a modal? Should it be a documented use case?

[benguhin]

@marteki thanks for pulling these together! The summaries are helpful as well.

To pull in some of the discussion from earlier in this thread, a lot of the known usecases for modals could also be satisfied by (1) including the content in an expandable section or (2) taking the user to a separate page (and they could then use the back button or a "Return to X" link to return to the content that they were viewing earlier).

Modals aren't a very accessible or mobile-friendly means of showing content on a page for a number of reasons, as @himedlooff notes above, so I think it's useful for us to ask when do we actually _need_ to use modals vs expandable sections or separate pages. Of the usecases listed so far, I think the only strong case for a modal is the "page is about to expire" warning. The FJ/V1 team has also talked about using a modal to alert users that click on external links that they are about to leave consumerfinance.gov, which also seems to be a strong usecase. In both cases, they're alerting the user to a significant change, not just providing content.

[marteki]

A first pass at a recommendation is here:

http://marteki.github.io/design-manual/ui-toolkit/modals.html

We're actively working right now at filling out the sections on accessibility, and creating the examples. In other words, the page will probably change every few hours. Still, start giving feedback and asking questions!

[marteki]

We think this is ready for approval!

Draft page: http://marteki.github.io/design-manual/ui-toolkit/modals.html

Approvers: @JenniferHoran @benguhin @nataliafitzgerald @Scotchester

[benguhin]

@marteki this looks really great – I love and approve the direction y'alls have gone with this. Do you have a google doc version so I can make suggested changes to the text?

[marteki]

We didn't have one before, but now we do! https://docs.google.com/a/cfpb.gov/document/d/1cxD7ZbSjK93edK_-lcvMPcuy4a0ObA5bie9qc9G4G2c/edit?usp=sharing

[Scotchester]

You addressed all my previous comments. The content on this page is FEWD approved :+1:

[JenniferHoran]

Hi!

I’ve never tested or used a video modal, so I would want to test that in a live environment. The rest look good for 508, as long as when I test them in a live environment all button and link markups are good for keyboard and screenreader/focus, and focus isn’t completely thrown off on a page once you close the modal.

[nataliafitzgerald]

Hi @marteki - This is looking good! I made some comments/suggestions within the GoogleDoc. https://docs.google.com/document/d/1cxD7ZbSjK93edK_-lcvMPcuy4a0ObA5bie9qc9G4G2c/edit#.

[benguhin]

:tada:

I also added some comments and suggested edits

[marteki]

Coolness! Here's my revision list:

• [x] Make suggested copyedits from Google doc
• [x] Rewrite or remove indicated sentences in Google doc
• [x] Check with @caheberer about "Cancel" link underline
• [x] Change screenshot with underlined "Cancel" link to one with no underline

[kurzn]

Modals page has been updated to follow new proposed content strategy guidelines here http://kurzn.github.io/design-manual/ui-toolkit/modals.html

@ascott1 and @designlanguage - as per the new approval process for updating content within an already approved page, I nominate you two as my peer reviewers to check over the page for things that don't make sense, errors, etc. Once you review it, please post here with a thumbs up/down and any comments.

Also, let me know if you don't have time to look this over and I'll choose a new reviewer. I'm hoping to get approval by next Wed, March 30.

[kurzn]

To clarify, we're looking for feedback on "are we organizing and communicating the guidelines clearly?" more so than "do you agree with how we propose using modals?" which has already been vetted with the approval team.

[designlanguage]

Hey @kurzn, I have a few comments about how the info is arranged, but overall this looks good.

• I'd prefer the examples of "When to use" not be their own category, but bulleted under the two specific use cases. That's already sort of the case (redundantly) under "Feedback or correction" with the parentheses. It could start with something like, "Examples of this use case include:"
• Under "Opening a modal", the second sentence (headline size) isn't about behavior. That's already stated in Content Guidelines, so I think it can be removed from this section.
• "No scrolling" might be harsh for a heading under behavior, but I wonder if there's a way to indicate that limitation in the headline for any tldr folks rather than just seeing "Scrolling". It could also be something more general like "Using a modal" and contain items like that there's no find function in a modal, etc...
• I understand that "Creating accessible behaviors" was mentioned separately because it's important, but it would be easier to follow if the accessible "Opening a modal" pieces, for example, were contained under that heading rather than being broken out. If special mention needs to me made, maybe that could happen in a sentence under "Behavior".
• Should there be a link to the form field guidelines where they are mentioned in "Content guidelines"?

[kurzn]

@designlanguage Thanks for the feedback! A few comments back:

• We originally tried it this way, but it got lost. Dividing them under their own header of "examples" made it easier to find when scanning, and also covers scenarios that overlap the 2 cases. For other types of components (since this is being used as a template for the future), this may be an even larger overlap, so it seemed the widest net to give them their own header rather than suggest they get divided into use cases across all components.
• Great catch! Remnant from before we had a sep content section
• I think this could be clearer than just "Scrolling" for the headline so I updated. The first sentence covers the do/don't, so hopefully that is simple enough for the tldr folks.
• I did move some of the behaviors under open/close as was pertinent, but some of these tips don't really fall under an existing behavior category. From earlier feedback we received, having some separate subheads for accessibility was pretty important.
• Added. Good suggestion.

[ascott1]

From a FEWD perspective this looks good, but I'm going to do some additional research around the accessibility content to make sure we're giving really good and clear instructions there. I'll report back!

[ascott1]

I'm sticking this here for reference https://accessibility.oit.ncsu.edu/training/aria/modal-window/

[kurzn]

:+1: Thanks @ascott1. We specifically didn't mention general things that are already baked into capital framework, as it felt duplicative. But if you find anything else modal specific, please share!

[JenniferHoran]

Modals are really great for forcing focus when for some other reason an alert or important piece of content isn't pulling focus for the AT user. But then there is the flip side where users hate too many pop-ups. I have a love/hate relationship with them. Sometimes when you are in something like SharePoint you have no choice but to build a box to pull focus since you are trapped in that authoring tool.

[ascott1]

Here's my first pass at extending the accessibility section a bit:

Creating accessible behaviors

Keyboard access should be limited to only interacting with the modal dialog once it is visible.

• The close minicon needs to be accessible from a keyboard.
• The escape key should also close the modal.
• The enter key should should be mapped to any submission forms in the modal.

Provide separate focus and hover states for the close minicon and any “next” action buttons.

The find function (ctrl+F) will not search information contained within a modal window when it is not shown.

Include offscreen instructions that describe the modal dialog and how to interact with it.

Specific development directions:

• Modal windows should be marked with aria-hidden="true" and toggled to false when visible and given the role=dialog ARIA role.
• When the modal dialog is displayed, the main content of the page should be marked with aria-hidden="true" to prevent screen readers from interacting with it.
• Add role="alertdialog" to the modal window.
• Code the close minicon using a button element for more semantic markup.
• The heading of the modal dialog should be marked as an <h1>.
• Offscreen interaction instructions should use the aria-labelledby attribute.

@kurzn @KimberlyMunoz @JenniferHoran @marteki I'd appreciate any feedback you have!

[kurzn]

@ascott1 I defer to you on this! I'm good with any way we can be more specific/inclusive of accessibility guidelines. I'll give this a few days to get additional feedback from those you've tagged, then I say we move forward with pushing this live! :) Thanks!

[JenniferHoran]

Happy to test anything you might have as a demo!

[kurzn]

@JenniferHoran We don't have a working modal in code yet, just the guidelines around how to create it for the DM page.

http://kurzn.github.io/design-manual/ui-toolkit/modals.html

This should be ready to publish now. Let me know if any other approvals/eyes need to be on it or what I need to do to get this up.

[kurzn]

@Scotchester The modals page is ready to go live. However, I don't believe we have this component built in capital framework. Do we want to wait to publish the page until it's been built or push this in the meantime?

[ascott1]

we want to wait to publish the page until it's been built or push this in the meantime?

I'm not @Scotchester, but I'd vote for publishing it before the CF component is built.

Additionally, I cam across this open source accessible modal over the weekend. By default it is un-styled, so we may be able to adapt it to our needs: http://www.humaan.com/modaal/

[kurzn]

@cfarm @virginiacc

Would either of you have time to create this in capital framework so we can publish the DM page?

[ascott1]

If the DM page is ready to go, it may be worth pushing this live now rather than waiting for the Capital Framework component. Then we have a documented design recommendation and we can add this to the CF backlog (if it's not there already).

[stephanieosan]

Status: This has an outstanding PR: https://github.com/cfpb/design-manual/pull/429 Recommendation: Make recommended changes, don't wait for Capital Framework, merge merge!