When a help dialog opens over an article, keyboard users need a clear way to leave it and return to the reading position. Keeping focus within a modal while it is open can be appropriate, but containment is not the same as trapping someone without an exit.
What a usable route looks like
Hypothetical example: a glossary dialog contains Definition, Related term, and Close. Pressing Tab moves through these controls and remains inside the dialog. Activating Close then dismisses the dialog and returns focus to the article control that opened it. This is containment with an available keyboard exit.
The route should be understandable from the interface. If Escape closes the dialog, that can be useful, but it should not be treated as the only possible method. Keyboard exit conventions can vary between interfaces. If a different command is required, the dialog should explain it visibly or through an accessible instruction.
How to assess the second version
Hypothetical comparison: in a second version, Tab continues cycling through the dialog, but there is no reachable Close control and no explained keyboard command. A user who entered the help content cannot return to the article using the keyboard. Record this as an inability to leave, rather than assuming that Escape will always work.
For a practical check, enter the dialog with the keyboard, move through every available control, and identify the exact action that returns reading focus. Do not infer success merely because focus stays inside the panel. Also check whether closing restores a sensible place in the article, instead of sending the reader to an unrelated control.
Reference
The W3C guidance on avoiding keyboard traps explains that keyboard entry must have a keyboard route out; a contained modal is acceptable when that exit is available, and a non-standard exit should be explained.