The overlay element should have appropriate ARIA attributes for accessibility. Consider adding role="presentation" or aria-hidden="true" when hidden, and removing it when shown. This helps screen readers understand that the overlay is a visual element and not interactive content. Additionally, the overlay should prevent focus from moving to elements behind it when the modal is open.

The scroll lock/unlock logic is duplicated between this file and src/pages/info/index.astro (lines 196-205). Consider extracting this into a shared utility function to reduce duplication and ensure consistency. This would make future maintenance easier and reduce the risk of the implementations diverging.

The unlockBodyScroll function doesn't check if a scroll lock is currently active before attempting to unlock. If called when no modal is open (e.g., double-clicking close button or pressing ESC multiple times), it could attempt to restore a scroll position that doesn't exist or is from a previous session. Consider adding a guard check to verify that dataset.scrollY exists before attempting restoration, or using a flag to track lock state.

When the modal opens, focus should be moved to the modal or its close button for better keyboard navigation and accessibility. Currently, focus remains on the trigger element. Consider adding modal.focus() or closeBtn.focus() after showing the modal to ensure keyboard users can immediately interact with or close the modal without having to tab through background elements.

Setting document.body.style.width = "100%" when locking scroll may cause layout issues on pages where the body has a different width configuration or uses max-width. On pages with scrollbars, this could cause a layout shift when the scrollbar disappears (as the body becomes fixed). Consider also setting the right padding to match the scrollbar width to prevent content shift: document.body.style.paddingRight = ${window.innerWidth - document.documentElement.clientWidth}px

When the modal opens and position: fixed is applied to the body, the scroll position is lost visually because fixed positioning removes the element from the normal flow. While the code correctly saves scrollY and restores it on close, if the user has scrolled significantly before opening the modal, the sudden jump back to that position could be disorienting. Consider adding scroll-behavior: auto temporarily during restoration to ensure an instant jump rather than a smooth scroll.

Similar to the transport dialog, if multiple modals can be opened simultaneously, the scroll lock implementation needs to handle this case. The current implementation overwrites document.body.dataset.scrollY which could lead to incorrect scroll restoration when closing modals in a different order than they were opened.

When the modal closes, focus should be restored to the element that opened it (the trigger). Currently, closing the modal doesn't restore focus, which can be disorienting for keyboard users as focus may jump to an unexpected location. Consider storing a reference to the trigger element when opening the modal and calling trigger.focus() when closing.

The overlay z-index is set to 100, which conflicts with the Nav component (src/components/Nav.astro:151) that also uses z-index: 100. This could cause layering issues where the navigation might appear above the modal overlay. Consider increasing the overlay z-index to at least 102 (modal is 101) to ensure proper stacking order, or better yet, use a higher range like 1000+ for modal overlays to avoid conflicts with other fixed elements.

The removed CSS properties 'align-self: center' and 'justify-self: center' were likely used for centering the modal. With the new approach using 'top: 2rem' and 'left: 2rem', the modal is now positioned explicitly. Ensure this change doesn't break the layout on various mobile screen sizes, particularly on very small or very large mobile devices.

In the mobile breakpoint, the modal animation direction has changed from translateX(-105%) (slide from left) to translateY(100%) (slide from bottom). This changes the user experience on mobile. If this is intentional to improve UX on mobile devices, this is good. However, if this was an unintentional change while adding the position: fixed scroll lock, it should be reviewed to maintain consistency with the original design intent.

Setting document.body.style.width = "100%" when locking scroll may cause layout issues on pages where the body has a different width configuration. On pages with scrollbars, this could cause a layout shift when the scrollbar disappears. Consider also setting padding-right to compensate for the scrollbar width to prevent content shift.

If a user opens the transport dialog while the member info modal is already open (or vice versa), the second modal's scroll lock will overwrite the scrollY dataset value from the first modal. When closing the modals, this will result in restoring to the wrong scroll position. Consider using a stack-based approach or namespaced dataset keys (e.g., dataset.scrollYTransport, dataset.scrollYMember) to handle multiple simultaneous modals correctly.

The unlockBodyScroll function uses delete document.body.dataset.scrollY to clean up, but it doesn't verify that all style properties are fully cleared. If the unlock function is called when styles weren't set (edge case), setting them to empty strings is harmless. However, consider also checking if dataset.scrollY exists before attempting deletion to make the function more defensive.

The scroll lock logic is duplicated between this file and src/components/page/MemberInfo.astro (lines 65-74). Consider extracting this into a shared utility function to reduce code duplication and ensure consistency across all modals.