This is an example of accessible tooltips, which can be triggered by mouse or keyboard, and are announced by screen readers when they appear.
Tooltips are triggered by focus or mouseover events, and are removed by blur events, by document-level click events, by triggering a different one, or by pressing the Esc key. They are not removed by mouseout events, nor do they disappear automatically after a timeout. These behaviours ensure conformance with 2.1.1 Keyboard and 1.4.13 Content on Hover or Focus.
Tooltips are created on the fly, and are associated with their triggering element via aria-describedby association, so that they're announced by screen readers when they appear. They also have role="tooltip", however this is just for semantic correctness, it doesn't actually make any difference. These semantics ensure conformance with 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value. The tooltip text itself is declared in custom data attributes, so it's not announced or rendered unless it's used to create a tooltip.
In order to simplify the positioning of tooltips, each triggering element is wrapped in a positioning context (i.e. an element with position:relative) and the tooltip is appended to that. This provides easy positioning without having to do complex viewport-position calculations (which would have to account for intermediate positioning contexts, variable box-models, scrolling offset, zoom, font-size etc.). However it is still necessary to detect viewport overlap, at the right or bottom edge of the window. Overlap is prevented when necessary by limiting the tooltip width and allowing the text to wrap, and/or by adjusting the top position. All of this ensures conformance with 1.4.4 Resize text and 1.4.10 Reflow.
The tooltip colors used in this demo conform to 1.4.3 Contrast (Minimum), and the tooltips remain clearly discernible, with a solid background and visible border, when viewed in Windows High Contrast mode (which could arguably be related to 1.4.1 Use of Color; although it's debatable whether that Success Criterion actually applies to the use of high contrast modes, it's undeniably a good idea to accomodate them either way).
However ... it's generally not a good idea to use tooltips at all. Relying on tooltips to convey information is generally a sign of inadequate user interface design. For example, if a tooltip is needed for users to understand the meaning of a graphical button, then either the icon is not obvious enough, or the button should have a text label. But if tooltips are going to be used, then they should only ever be used to provide supplementary information, and not be relied upon to provide a control's accessible name. Accessible custom tooltips such as these are always preferable to the use of title attributes, since the native tooltips created by title attributes are far less accessible. Native tooltips can't be triggered by keyboard, they might not be announced by screen readers (or if they are, they might override the element's text), they're not persistent, they generally don't accomodate increases in zoom or text-size, and their appearance can't be modified by user stylesheets.