Closed mattgarrish closed 1 week ago
Using a11y: makes sense as these are accessibility related data. If something is specific to Braille, like the # of cells then something like
a11y:brailleCells="8" or a11y:brailleDots="6" - would make sense.
Where something can be more accessibility generic the word "braille" would not be included such as:
a11y:remediatedBy, a11y:transcribedBy, etc.
Right, we may want to look at some names to make sure they aren't relying on the brl prefix to make sense.
I think this is a solid approach. I like that it gives us opportunities for the future as well as our current eBraille developments.
Although it's possible to add a new reserved prefix, it comes with a cost of full compatibility with EPUB 3 unless a prefix is always declared or we try to get the epub spec amended to add a new reserved prefix (which could be difficult as it's probably a feature request and epub is in maintenance mode).
To avoid these issues, it's probably better to define the needed vocabulary terms in the existing a11y: prefix namespace. That will give us full compatibility without the prefix declaration headaches.
It has the side benefit of making the terms we define more generally usable for future accessible formats. Using a brl: prefix suggests they are only usable for braille, while some like an a11y:contributor property would be useful no matter the format.