- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Mon, 24 Jun 2013 18:16:23 -0500
- To: "public-indie-ui@w3.org"@us.ibm.com
- Cc: janina@rednote.net
- Message-ID: <OF6057B525.363FDF3A-ON86257B94.0077C747-86257B94.007FD938@us.ibm.com>
Review of user context:
I am not sure why it did not make it into the key value pairs but:
1. We should support this AccessForAll key value pair from the AccessForAll
specification:
|
|
Attribute name | atInteroperable
|
|
-----------------+----------------------------------------------------------------
|
|
Data type | Boolean (see Table A1.1).
(Range) |
|
-----------------+----------------------------------------------------------------
|
|
Value space | · False – denotes that the user does not require assistive
(Domain) | technologies support;
|
| · True – denotes that the user does require assistive
| technologies support.
|
-----------------+----------------------------------------------------------------
|
|
Refines | N/A
|
-----------------+----------------------------------------------------------------
|
|
Multiplicity | [0..1]
|
-----------------+----------------------------------------------------------------
|
|
Linguistic | Non-linguistic
Indicator |
|
-----------------+----------------------------------------------------------------
|
|
Description | A preference for resources that is compatible with assistive
| technologies.
|
-----------------+----------------------------------------------------------------
|
|
Notes | Resources that are interoperable with AT should be selected
| whenever possible. Interoperability is indicated by
| compliance with WCAG 2.0 checkpoints: 1.1.1, 1.3.1, 1.3.2,
| 2.4.4, 3.1.1, 3.1.2, 3.3.2, 4.1.1 and 4.1.2.The specific
| details of the AT are normally provided by a user agent or
| the operating system. The example of ‘atInteroperable=true’
| expresses this statement: “resources that are interoperable
| with AT should be selected whenever possible”.
|
This gets us away from having to declare that what assistive technology is
supported to get the author to support interoperability with the assistive
technology. This would need to be set if the user wanted to test the site
with an accessibility test tool, a functional test tool, a screen
magnifier, a screen reader, or an alternative input device where
accessibility information needs to be exposed to the browser which can
intern expose it to the assistive technology.
This key is also valuable for people producing graphics for big data and
the user may wish to render alternative content for a graphic to be
interoperable with an assistive technology if it is not already
interoperable.
2. The exposure of ScreenReaderSettings is an independent discussion from
ATInteroperable and it should be vetted by a wider audience to make sure
that it can be accepted - even with domain-specific privacy settings. I
would like to hear what Judy's thoughts are regarding casting a wider net
on this. The other question is should the screen reader settings go out in
the first public working draft before a wider audience has looked at it? At
the very least the concerns of the group should be placed in a note with
that screen reader text to highlight the issues around exposing it? At this
point there does not seem to be consensus on having it in there but we
should talk about this on Wednesday's call.
A second issue with ScreenReaderSettings is having authors code to a
specific screen reader. So, exposing name and version numbers is an issue.
I personally have issues with this, expecially after what happened with
role="application" where the role was added to get around a bug in one
screen reader.
3. Currently, we only address language preferences for subtitles. However,
we don't specify this for the entire document. For completeness we should
include this
1.1 LanguageOfAdaptation’ Attribute Description
Table 3.8 The ‘languageOfAdaptation’ attribute for the Access_For_All_User
class.
|
Descriptor | Definition
|
-----------------+----------------------------------------------------------------
|
|
Attribute name | languageOfAdaptation
|
|
-----------------+----------------------------------------------------------------
|
|
Data type | NormalizedString
(Range) |
|
-----------------+----------------------------------------------------------------
|
|
Value space | See Table A1.1.
(Domain) |
|
-----------------+----------------------------------------------------------------
|
|
Refines | N/A
|
-----------------+----------------------------------------------------------------
|
|
Multiplicity | [0..unbounded], unordered
|
-----------------+----------------------------------------------------------------
|
|
Linguistic | Non-linguistic
Indicator |
|
-----------------+----------------------------------------------------------------
|
|
Description | A preference for the language of the adaptation [RFC4646].
|
-----------------+----------------------------------------------------------------
|
|
Notes | The example of ‘languageOfAdaptation=spa’ expresses this
| statement: “resources in Spanish should be selected whenever
| possible”.
|
We should specify this a list of space delimited ISO639 language codes
similar to those for the video tag.
4. LightOnDark display setting
Windows has black on white which is the reverse. Why are we only using
LightOnDark? Should we include it?
5. Introduction of a Note regarding high contrast color schemes and other
media queries that we are deferring to rather than providing settings for
them here. The fact that we are not providing "white on black" and
"blackonwhite" color schemes is rather significant given that Windows
supports these settings. I think it is prudent that we have some sort of
Note to the effect that our spec. is not providing these features as they
will be incorporated into future CSS Media Queries.
If we can address these points in the group I would support our going to a
first public working draft for User Context. There are other attributes we
could add but I think these are sufficient, even with the TBDs for now.
Rich Schwerdtfeger
Received on Monday, 24 June 2013 23:17:31 UTC