Fixes #260. Clarifying cover infoset requirements. #266
Conversation
|
I'm still uneasy with the first sentence in that it normatively indicates how a user agent is expected to provide access in a bookshelf, etc. That isn't specifically related to the cover or its compilation from the manifest. It's sort of light foray into UAAG territory. We might want to reconsider whether these points need saying, or if there's a way of referencing UAAG, where relevant, in the user agent section. |
|
Yeah, I was thinking about that. I was mostly just addressing the lack of clarity in my rewriting, and not addressing the overall point of the initial statement, which did address UAs. Because in a straight-up description of the infoset, no part of this statement belongs, but it does have to exist somewhere. I mean, it could be something like:
It's not normative, but at least it's explicitly stated. I'm beginning to think that we need "WP Accessibility" to parallel EPUB Accessibility. If we remove this, it won't be the first accessibility statement we've removed from the draft because it didn't belong in the definition of WP, per se, but that nevertheless needs to be documented as a minimum for WP accessibility. The reality is that, just as with Epub Accessibility, we're going to have some requirements or recommendations that aren't encapsulated by WCAG or UAAG, and we need to record them somewhere. |
|
I'm going to close this as we've addressed it, I believe, through #273. There is a "should" to include a title and description and an example of their use. And just because it's odd to come off sounding like I'm advocating against accessibility, I think there are relevant statements being raised here that we should take up when we address how features are implemented. It's just that at the infoset level that we should only be concerned with "affording" features, like accessible interfaces, and I believe we have that. |
Preview | Diff