[feat]: <rh-footnote> ready for development #740
Description
Tag Name
rh-footnote
Purpose
Provides a pattern/component for displaying footnotes. [XD link]
Distinguishing factors
No response
Where will it be used?
- Used on redhat.com (example pages: Our Company, Resources article)
- Can be used with stat component
End user
Designers and content creators
Intended end use
- Clicking the footnote link will show a popover with additional information or a reference.
- Traditional list of references will still be available at the bottom of the page. Is there a way to auto-populate the popovers' content into a list at the bottom? (May be a question about Drupal implementation.)
Properties
- The footnote's superscript size depends on the body text font size.
- The footnote isn't a superscript at font sizes 14pt and lower to prevent it from being too small. At this size, font weight and character spacing should match body text.
- Popover component should handle position and orientation of popover.
Page Builder
- My component will be part of a page-builder experience
- I'm not sure
Accessibility Features
- Color: Color should not be the primary visual means of communicating information (1.4.1)
- Content or microcopy Text in any language should be clear, meaningful, structured, etc.
- Text Contrast: Small text should have a contrast ratio of at least 4.5:1 (1.4.3)
- Text Contrast: Large text should have a contrast ratio of at least 3:1 (1.4.3)
- Resizable Text: Text should have the ability to be resized up to 200% without losing content or functionality (for example, horizontal scrolling) (1.4.4)
- Alt Text: Non-text elements should have concise text descriptions (a.k.a. alt text) (1.1.1)
- Keyboard: Descriptions of how interactive elements behave when a key is pressed should be included (2.1.1) (for example, the Esc key closes a navigation menu)
- Focus Appearance: Colors between focused states should have a contrast ratio of at least 3.1 (2.4.11)
- Focus Appearance: Borders should have a thickness of at least 2px (2.4.11)
- Focus Order: It should be logical how a user moves focus from one element to another (2.4.3)
- Motion Animation: Controls should be available to disable an animation triggered by an interaction (2.3.3)
- Mobile: Interactive elements should be reachable for touching, scrolling, or dismissing
MVP Requirements
- Correct styles and neccessary sizes, orientations, variants, spacers, and themes
- Responsive sizes and page layout examples placed on screenshots
- Functionality guidance and static animation frames or prototypes with motion
- Interaction and Selected states
- Alignment options, character counts, and necessary translations
- Clear and structured content, acceptable text contrast, and logical keyboard events
Appearance
- Foundations are represented as tokens or variables (border, color, font, opacity, spacing, shadow, etc.) [Consult with the assigned developer to ensure you are both working with the correct styles and values]
- Foundations are applied to elements (backgrounds, buttons, fields, icons, links, etc.)
- Size (Standard, Compact, Mini, etc.)
- Orientations (horizontal or vertical)
- Position in relation to trigger (top, right, bottom, left, etc.)
- Hierarchy and decoration variants (Primary and Secondary CTAs, Earth and Wind variant Tabs, etc.)
- Decorations (borders, logos, UI icons, etc.)
- Desktop and mobile scale spacers (visit the Spacing and Typography pages for examples)
- Themes (light, dark, high-contrast, custom color, etc.)
- Edge cases or limitations (accessibility, brand extensions, horizontal scrolling, missing images, etc.) [It is not required to include all of these specs, but keep them in mind]
- Fallback (if a browser does not support the original design) [Consult with the assigned developer first to determine if this is necessary to design]
Page Layout
- Location on page (navigation, hero, band, card, footer, etc.)
- Grid (fixed width inside the grid, full-width or outside of the grid)
- Position on page (inline, overlay, toast)
- Stacking (space in between each instance if your component is meant to be repeatable)
- Responsive screen sizes (desktop, tablet, mobile, etc.)
- Content degradation (becomes hidden, reduces in size, truncates due to length, etc.)
- Scrolling behavior (fixed, sticky, content scrolls inside; visit this page for examples)
Behavior
- Functionality (collapse, expand, navigate, play, submit, etc.)
- Animation or motion (hover, jump, slide, stack, toggle, etc.)
- Overflow (when content exceeds a defined boundary; visit the Tabs page for examples)
- Other effects (blur, cover, shuffle, etc.)
States
- Interaction (default, focus, hover, active, disabled, dragged, etc.)
- Selected (if a user needs to distinguish between active or inactive content)
- Steps (if a user needs to move through steps toward the completion of a task)
- Error (if a user needs to complete a task or fix an issue before proceeding)
- Severity (if a range of status options need to be communicated to a user)
- Boolean (if on or off are the only actions available to a user, literally or semantically)
- Skeleton loading (if a component might load slower for a user than expected)
- Empty (if data cannot be displayed without user input; visit this page for examples)
- Fallback (if JavaScript is disabled or it fails to load) [Consult with the assigned developer first to determine if this is necessary to design]
Content
- Alignment options (left, center, or both)
- Character counts (minimum and maximum)
- Links (which links are inline, external, redirects, etc.)
- Translations (German, Japanese, Hebrew, etc.)
- Edge cases or limitations (overflow, truncate, wrap, etc.) [It is not required to include all of these specs, but keep them in mind]