The most reasonable implementation to me at first sight:
create a --USER__a11yFocus flag (custom prop), since we already have a --USER__a11yNormalize;
outline’s customization can be handled in day, sepia and night mode modules, like ::selection.
But then it’s about UX i.e. is this an explicit = user can turn it on/off, or implicit = automatically enabled depending on some conditions?
Also, we’re (finally) entering FXL territory for this one. So maybe it would be a better idea to make focus its own module and then re-customize it in the sepia and night modes only.
Feedback from Daniel:
Yes, as a matter of fact I was running tests this week, as part of a DAISY activity where we are in the process of defining good practice recommendations for content creators (aka production guidelines), specifically in the context of extended descriptions (typically, for images ... but this can apply to complex information structures like tables too).
Semantically we can leverage existing / upcoming techniques (including fallback mechanisms for non-supporting user agents / reading systems) such as aria:details and aria:describedby, alongside HTML5 <details><summary>, or <aside epub:type="footnote">, etc.
Stylistically, we can use :active and :hover for link interactions, :active to "highlight" link destinations (i.e. to emphasize the point of regard of navigation targets), typically with CSS outline styles rather than border (as the latter usually messes-up the border-box model of arbitrary EPUB HTML documents).
Problem: several EPUB reading systems (including Readium(1), iBooks iOS/OSX, Edge) seem to interfere with URL anchor / fragment identifier, thereby breaking CSS :target pseudo-class. This is something I have been keen to get right in Readium2, where the navigation logic (link activation) is also "hijacked" by some kind of reading system logic, especially in Electron as we listen to <a> DOM click event, as well as higher-level / platform-specific navigation events via a WebView API (which allows us to capture the annoying window.location programmatic redirects that InDesign uses, among other things).
So, going back to the question at hand: should ReadiumCSS allow apps to opt into aggressive style overrides (!important) for common user interactions such as :focus, :target, :active, :hover, etc.?
Well, given that ReadiumCSS can already force (over authored styling) "colour themes" and various other visual formatting rules, it seems logical to allow reading systems to ensure consistent styling for the aforementioned interactions too, some possibly customizable via user preferences, for example the thickness of the :focus outline, or whether or not to enable :target emphasis at all (for people who have difficulty to find the point of regard when following hyperlinks).
Must still think about the best option to implement that. At first sight, it looks like a good candidate for a dedicated module, a little bit like the OS_a11y one, especially as implementers may want to use it in fixed-layout as well.
We’ll need this for a11y, see issue #18.
Feedback from Daniel:
Must still think about the best option to implement that. At first sight, it looks like a good candidate for a dedicated module, a little bit like the
OS_a11yone, especially as implementers may want to use it in fixed-layout as well.