The context for this is that I'm working on a NextJS project that depends on persistent state management. Next handles navigation between pages using their own Link component. I wanted to make a fork of the LinkBox component, modified slightly to use Next Link instead of our built in link utility. When I copied over the source for the component, and updated all of the imports to pull from '@UA-Stratcom/minerva', typescript had several issues.

## Description

When installing minerva as a package, it would be helpful to be able to import type declarations for use in custom components or to extend minerva components, respecting the component interfaces. To do this, one would expect to import the type like below:

```tsx
import type { icon } from "@UA-Stratcom/minerva";
```

However this doesn't work, as the types themselves are not exported in the compiled types.d.ts file that is distributed with the package.

## How to Reproduce

Steps to reproduce the behavior:

1. Create a NextJS app (you can use the starter template)
2. Try creating a new component, but using one of Minerva's types in the props
3. Import the type from Minerva using the syntax above
4. See errors

## Expected behavior

We should have a way for users to import our types for use in their own projects

## Screenshots

If applicable, add screenshots to help explain your problem.

## Additional context

I looked into this for quite a while late last night and I'm pretty sure there's some configuration issue in one of the files: `package.json` `rollup.config.js` or `tsconfig.json`

I tried asking Copilot and while it did provide some interesting advice, I think it doesn't understand the intricacies of how our package is built for distribution, since it passes through several steps.

## Side note

It would be very cool if we could figure out a way to easily use Next Link instead of our link utility without adding Next as a dependency. The only way I can imagine doing this would be either some global level configuration file, which seems extremely complicated, or find someway to replace our Link utility component with a custom one that wraps Next Link so that the props are all the same, just parsed and passed through to Next Link. I'm not sure how to get Minerva to recognize the new component as an override for the existing Link utility. Since our React projects are mostly in NextJS, it may make sense to dedicate some time to solving this issue.

An issue related to developer experience or operations

Minerva 1.6.0

Can't import types from minerva when installed as a package

## Description

UA has held this very sharp edge design for about 5 years now, and recent concepts have floated the idea of rounded corners. We need to look at the design system as a whole and determine how rounded corners fit into the design system, and what it means for existing components and overall visual language.

design

Anything related to architecture / refactors / project structure

core

Evaluate addition of border radius

## Description

WordPress now supports box shadows in the editor, with several enabled by default. @spbrown6 and I talked about this briefly during the last all staff meeting, and decided we would look into how box shadow effects could be applied throughout the design system.

Box shadows don't necessarily have to be the feathered drop shadows that come to mind, they can be solid and bold or even outlined offsets.

We need to determine the following:

- Are box shadows permitted by the design system
- If so, what presets are there to choose from
- How should those presets be used
- Should they be worked into the default design of any components
- If not, what usage guidelines will we have for box shadows

There may be other questions we run into during this exploration, but those are the big ones that need to be addressed. Basically, how do box shadows fit in the design system.

Evaluate addition of box shadows

blocked

enhancement

Development for Timeline component

## Description

A mockup should be produced following the Minerva design system with annotations for developer handoff. All designs will be considered, but a vertical layout will likely be the most straightforward. The timeline should account for arbitrary content length, a date, and an optional image.


Design for Timeline component

## Background

We've had a couple of requests for a timeline block, and even needed a solution for this on UA home. We ended up going with the workaround below, but it would be nice to have a full fledged component to handle this type of content.

## Description

This is a proposal for a new component that would allow users to display content along a timeline.

## Workarounds

Currently, there are probably multiple ways to display this information but the workaround we used on home was to use headings and content very much like a standard page.


A task related to planning / project management

planning

Timeline Component

## Description

This is a list of things we need to double check to make sure we're in line with the new WCAG 2.2 guidelines.

```[tasklist]
- [ ] 2.5.3 For UI components with labels that include text or images of text, the name attribute contains the text that is presented visually
- [x] 2.5.2 For functionality operated using a single pointer, one of the following is true: The down event is not used to trigger any action, the action can be aborted or the action can be undone, the up event reverses any outcome of the down event, or completing the action on the down event is essential
- [ ] 4.1.3 Status messages can be programmatically determined through role or properties such that they can be presented ti the user by assistive technology without receiving focus
- [ ] 1.4.11 Graphics and UI components must meet contrast guidelines
- [x] 1.4.12 When the following is set by the user: Line height at least 1.5, space between paragraphs at least 2em, letter spacing at least 0.12em and word spacing at least 0.16em, no part of the UI becomes unusable
- [ ] 1.4.13 This is a long one that pertains to content revealed on hover or focus
```

## Notes

For 2.5.3, we mostly just need to check any label elements and make sure the name attribute matches the text inside the label

For 2.5.2, we need to look through all of our JS and make sure nothing is triggered on the mouse down event

For 4.1.3, I need to do some more research on what exactly qualifies as a status message, but this will likely only apply to the alert banner on home. Its possible the Callout component could be used as a status message, so we may need to add a prop to that component to indicate if its an alert or not. I'm wary of this however because I fear content editors will abuse this option. If the Callout component gets this new prop, it should be a checkbox in the theme with a warning beneath it explaining what that checkbox is for and discourage it's use.

For 1.4.11, I need to do some research on what the WC3 classifies as a "UI Component". This could potentially be a lot of trouble if things like cards are included, and may require a re-think of how we handle the color system

For 1.4.13, I'm going to verify that applies to dropdowns on the main navigation. If it does, it may mean we have to change how this component functions.

## Important

This issue is not meant to fix any accessibility violations, only identify if a fix needs to be made. **If we discover anything in violation of these new guidelines, we should open a new accessibility issue to track it specifically.**

Use this thread to discuss these guidelines and their impact on our web framework.

research

Review for WCAG 2.2 Compliance

## Description

When adding a primary navigation item that is set to open in a new tab, the icon appears on the next line under the navigation label. 

## How to Reproduce

Steps to reproduce the behavior:

1. Go to menu editor
2. Add a menu item
3. Select "open link in a new tab"
4. See error

## Expected behavior

The icon should appear beside the navigation label.

## Screenshots

![Image](https://github.com/user-attachments/assets/91c9da73-62bd-47c1-8b5c-9868fe4472f5)

## Device Information

- Operating System: OS X 10.15.7 64-bit
- Browser: Chrome 134.0.0.0
- GA Supported: Yes
- Cookies Enabled: Yes
- Browser Size: 1920 x 934
- JavaScript Enabled: Yes
- Browser User Agent String: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36


Minerva 1.5.0

Primary navigation "open link in a new tab" icon appears on line under label

## Description

The accessibility checker in StoryBook flagged this violation on the CodeBlock component. Scrollable regions must have keyboard access so that they can be scrolled with the keyboard.

This is a violation of [WCAG 2.2 § 2.1.1](https://www.w3.org/TR/WCAG22/#keyboard)

## Additional context

StoryBook provided this link for more information:
https://dequeuniversity.com/rules/axe/4.9/scrollable-region-focusable?application=axeAPI


An issue related to an accessibility concern

accessibility

Codeblock: Scrollable region must have keyboard access

@spbrown6 and I looked at the styling for the contact card with a bunch of entries in a grid and compared the component to the Card setup we've been advising people use for these kinds of people lists. Below are some changes requested to the design:

1. There is an extra gap between the image and first heading, seemingly caused by the selector here:

```css
.ua_minerva .ua_card > * + * {
  var(--ua_space--flow-half, calc(var(--ua_space--flow, 2rem) / 2));
}
```

I'm not sure why this was added, so care should be taken in removing it. I think the selector was probably supposed to be `.ua_minerva .ua_card_content-wrapper > * + *` but I could be wrong. It just needs to be tested to see what's going on there.

EDIT: I'm actually unable to reproduce this issue in Minerva, so the offending CSS may have been added in the theme.

2. Update the styling for `contact-card_info` so that it has a margin-top of 2 (I think that's flow half?) with text size and line height small.
3. Adjust the card title to use medium line height
4. Add margin-top of 1 for `ua_card_subtitle`
5. Add additional space to the right of the icons in the info section by 0.25em. The selector for that should be `.ua_minerva .ua_contact-card .ua_contact-card_info .fa`
6. Change the typography for `.ua_contact-card_content` to be UI copy
7. Finally, remove the "view profile" button entirely and add the link to the card title instead. This will also require the removal of the default Card hover and focus effects, as well as the anchor before element that makes the entire card clickable.

ContactCard design update

## Description

When importing the TitleBar component in a NextJS app utilizing Server Side Rendering, it will produce an error that "useEffect" can only be run on the client side.

## Additional context

Looks like this component was overlooked from the 1.4.2 release that added the 'use client' directive to components using useEffect.


TitleBar doesn't work with SSR

## Background

The case for link accent is more for dark mode and high contrast areas as a way to allow crimson 300 to be used for things like borders and UI elements that may otherwise be turned white simply because text links need to be white for contrast purposes.

The case for background--info-alt, background--negative-alt, and background--positive-alt is to provide what would essentially be background--element within those contexts. It's possible to dispute the naming of these variables to follow the "surface, element, chip" schema, especially since this solution still wouldn't provide an acceptable color for chip within that context. That being said, I think these contexts are used so infrequently and with much control, and it is incredibly unlikely to need a chip color for each context.

## Mockups / Proposed solution

Add the following tokens to the design system:

- ua_color-text--link-accent
- ua_color-background--info-alt
- ua_color-background--negative-alt
- ua_color-background--positive-alt


Proposal: new color variables text--link-accent and background--context-alt

## Background

The College of Arts and Sciences reached out to me and Kyle about a dark theme for some of their websites that usually have a darker aesthetic, and wanted to see how that could fit with the minerva design language.

## Description

Implement support for a dark or inverse theme

## Workarounds

`ua_contrast--most` can be added to a wrapper around most page content and things work reasonably well. However, more contrast sections and some components respond poorly to this


Add support for dark mode

Reported by Heather Baker on the web forum (heather.a.baker@ua.edu)

## Description

Are there any plans to update (or include alternate colors via classes) duotone colors for font awesome icons with numbers or symbols in them? Some of our departments requested to use link boxes with icons instead of steps blocks, but the [number icons](https://fontawesome.com/search?o=r&c=numbers&s=solid&ip=duotone) with circles or squares around them end up with insufficient color contrast due to the current red text on red background duotone colors. (Attached is an example of the different styles of font awesome numbers in duotone.)

## Screenshots

![image](https://github.com/user-attachments/assets/8ff7edd0-914b-4fcd-8627-d6562fbc5fd8)


Roadmap

Milestones

Minerva 1.6.0

Minerva 1.5.0