Content on accessibility

[fsteeg]

Some content on accessibility, going through the W3C checklist, as discussed in our meeting. Two things that I noticed (see also inline TODOs):

• Setting a specific size in the preview service might conflict with clients wanting to provide scaled interfaces for improving accessibility. Do we even need a size here at all? It seems to me the rendering should be up to the client, and the HTML served should be as presentation-independent as possible (no fixed font sizes etc.). We could then remove the preview metadata altogether. If we do need a size, it seems it should be set by the client, not the service. Like, in a header or query parameter of the preview request?
• Unlike all other objects (like entities, types, and properties), matching features have no name. To provide a uniform way of displaying useful labels, I think we should add that.

I was considering opening issues for these two points, but since they are motivated by the accessibility content here, maybe it makes sense to work on that as part of this pull request?

(There is also the whole internationalization / multilingual support topic, which is very relevant for accessibility, but we have a separate issue for that: #52).

[thadguidry]

From our current specs...

This section specifies how reconciliation services can provide embeddable HTML previews of their entities, which clients can display in their user interface.

width The width in pixels of the viewport where to render an entity preview;

height The height in pixels of the same viewport.

Hmm, so I would say that it probably is still useful for a client to know what viewport size to use for a preview viewport. Or put another way...what are the reasonable dimensions that look adequate for the amount of information that a preview is going to push into a viewport. Some recon service might have LOTS of metadata and others might just be 1 line/sentence, i.e. a dictionary definition. You might build a client with Electron or Tauri and then use the width/height information to setup the preview window specifically or alter it given some user accessibility preferences (iPhone give me EXTRA LARGE text please). In OpenRefine we envisioned that later on we might even have a completely different iframe or browser tab for reconciling against services that have lots of disambiguating information about their entities to push into a preview.

1. Knowing what the original intended size (or tested size) of the minimum viewport needed from the recon service would help? So, I think that's why we have the width/height there in the specs currently. But do things get magically cutoff or loss of information through a viewport on a client that did not size enough for the minimums of the service...probably so?

2. or scrollbars should be expected...and we mention that in the specs...that a client may handle a viewport differently and should think about accessibility and at a minimum offer scrollbar support (horizontal/vertical) in case viewport size minimums cannot be met for some reason on the device or client?

[fsteeg]

I've updated this as discussed in our December meeting, see commits above for details.

[thadguidry]

Yes very nicely done and worded. Thanks @fsteeg !

[fsteeg]

Thank you both! Merging.