Skip to content
BeeUI

Visually Hidden

Visually Hidden

Section titled “Visually Hidden”

Keeps non-interactive assistive content in the accessibility tree while removing it from visual layout.

Identity

Section titled “Identity”

Import

Section titled “Import”
import { VisuallyHidden } from '@beemvp/beeui-ui';

There is no documented deep/private source import. For source ownership from a BeeUI checkout:

Terminal window
pnpm beeui -- add visually-hidden

Registry metadata: registry/registry.json.

Composition and public API

Section titled “Composition and public API”
  • Primary export: VisuallyHidden

Exported types: VisuallyHiddenProps

The generated API inventory is mechanically joined to packages/ui/src/index.ts, Registry metadata, and the component reference contract. For behavior details and defaults, use the canonical component behavior catalog rather than copying TypeScript declarations into a second hand-maintained table.

State and behavior contract

Section titled “State and behavior contract”

Controlled/uncontrolled props, callbacks, disabled semantics, normalization/fail-safe behavior, and mount/unmount rules are defined by the public types and the canonical behavior catalog. The executable fixtures below are the source-grounded usage examples; consumers should not infer state ownership from DOM structure or another UI library.

Provider and dependencies

Section titled “Provider and dependencies”
  • No additional provider is required by this family. BeeUIProvider remains the recommended application root.
  • Peer/native dependencies visible to this Registry item: react, react-native
  • Registry dependency closure: theme
  • Safe-area ownership remains explicit: shell surfaces touching system edges opt into SafeArea; components do not silently invent app-shell insets.
  • Web consumers load the BeeUI semantic theme CSS as documented in Web onboarding.

Platform behavior

Section titled “Platform behavior”

The same public family is exposed across the supported target matrix; meaningful platform differences remain governed by the compatibility contract.

  • Web: live browser/keyboard behavior is verified by Web-specific checks where applicable.
  • iOS / Android: package/export/native compile evidence is not described as device-runtime proof. Consult the compatibility and native-preview guides for the exact evidence class.
  • Platform-specific or experimental behavior is called out in the canonical component/compatibility docs rather than hidden behind a generic parity claim.

Accessibility

Section titled “Accessibility”

Use the Accessibility overview, RTL/localization, and Large text & zoom alongside this family. Roles/states, keyboard/focus behavior, announcements, Dynamic Type/Web zoom, RTL, and reduced-motion expectations remain component-specific; BeeUI does not claim universal accessibility certification from automated tests.

Styling and theming

Section titled “Styling and theming”

BeeUI components consume semantic tokens and support the current typed variant/density contracts. Use Theming and Density. className is an implementation escape hatch for source-owned/application work, not a cross-engine portability guarantee.

Executable examples

Section titled “Executable examples”

Open the matching Web runtime in Showcase. The Showcase link demonstrates Web behavior; use the native-preview guide for real simulator/emulator/device paths.

Live Web preview

Section titled “Live Web preview”

This frame loads the real BeeUI Web Showcase on demand; it is not a second docs-only implementation. It proves browser behavior only. Use native preview for iOS/Android simulator, emulator or device paths.

Composition anatomy

Section titled “Composition anatomy”
  • Family root / primary export: VisuallyHidden
    • Exported type surface:
      • VisuallyHiddenProps

The tree above is ordinary document structure so it remains readable with keyboard and assistive technology; it is derived from the real public export family rather than a canvas-only diagram.

Verified example source

Section titled “Verified example source”

The following is the exact typechecked runtime Showcase fixture selected for this live preview: apps/showcase/component-gallery/public-doc-fixtures.tsx. Runtime gallery/pattern sources are preferred over test harnesses, and the displayed source and executable source are the same file; there is no separately maintained demo snippet.

import {
  Calendar,
  Card,
  FormMessage,
  Label,
  MetadataRow,
  Section,
  Text,
  useBeeToken,
  VisuallyHidden,
  VStack,
} from '@beemvp/beeui-ui';
import * as React from 'react';


/**
 * Small runtime surface for public families that are otherwise consumed only by
 * tests, private composition internals, or generated docs. Keeping these here
 * gives the public docs a real, typechecked Showcase source instead of falling
 * back to test/mock files.
 */
export function PublicDocFixtures() {
  const [date, setDate] = React.useState({ day: 3, month: 9, year: 2026 });
  const primary = useBeeToken('colors.primary');


  return (
    <VStack gap="lg" testID="public-doc-fixtures">
      <Card className="gap-4" padding="lg">
        <Section
          description="Public primitives that are normally embedded in larger application compositions."
          title="Documentation runtime fixtures"
        >
          <VStack gap="sm">
            <Label required>Project name</Label>
            <FormMessage>Example validation message</FormMessage>
            <MetadataRow
              description="Read through useBeeToken from the active Uniwind theme."
              label="colors.primary"
              value={String(primary)}
            />
            <Text>
              Visible companion text for the assistive-only content rendered immediately after it.
            </Text>
            <VisuallyHidden>
              <Text>Assistive-only VisuallyHidden fixture</Text>
            </VisuallyHidden>
          </VStack>
        </Section>
      </Card>


      <Card className="gap-4" padding="lg">
        <Section
          description="Standalone controlled Calendar using the same public API consumed by date-picker compositions."
          title="Calendar"
        >
          <Calendar onValueChange={setDate} value={date} />
        </Section>
      </Card>
    </VStack>
  );
}

Use the code block’s copy affordance to copy the exact fixture. For a smaller app-specific example, start from the public imports shown above and keep only the state your screen owns.

Limitations

Section titled “Limitations”

Never a substitute for labelling an interactive control.

Section titled “Related”