Re: Discussion: Applications

Hi Peter,

Good example, thank you. I'm still unclear how generalizable it is, 
especially with respect to demonstrating non-interference, but it does 
help to have a concrete example to think about.

Regards,
   Shadi


On 6.4.2012 02:58, Peter Korn wrote:
> Hi Shadi,
>
> To your last question about amount of work to make something that is duplicated
> elsewhere accessible in both instances vs. verifying non-interference... a real
> life example is setting tab stops and margins in an editor. We dealt with this
> in an office suite I was helping make accessible.
>
> A mouse user can do this by clicking first on the image of the tab stop type
> (left align, right align, centered, decimal-point centered) and then
> clicking/dragging along a graphic of a ruler above the text, perhaps with a
> light visible vertical bar overlaid over the text for aid in alignment. Using
> essentially the same UI, a mouse user might adjust the margins. A keyboard user
> can bring up the paragraph's tab&  margins dialog box, and use a combo box or a
> new button to choose an existing / new tab or otherwise adjust an existing
> margin, and then enter the position along the rule in whatever the document's
> measurement units are.
>
> We looked at making the ruler keyboard accessible, and extending the
> accessibility API to cover it. We decided that the functionality of setting tab
> stops and margins was fully duplicated with the pre-existing dialog box, which
> was very straightforward to make accessible since it was based on the stock UI
> components that were already accessible. Verifying non-interference was also
> straightforward. And... since setting/resetting the margins and tab stops is
> done a relatively small percentage of the time (compared to simply entering and
> editing text), the fact that a keyboard only user - including of course a screen
> reader user - has to take significantly longer at the task than a mouse user
> still has an overall very small impact on the productivity overall - again
> another argument for not investing a significant amount of time to make this
> type of - duplicated - user interaction accessible.
>
>
> Regards,
>
> Peter
>
> On 4/5/2012 5:45 PM, Shadi Abou-Zahra wrote:
>>  Hi Peter, All,
>>
>>  Good point about the functionality of individual page elements versus the page
>>  as a whole. I would personally interpret the latter from the WCAG 2
>>  conformance requirement 5 on "non-interference":
>>  -<http://www.w3.org/TR/WCAG20/#cc5>
>>
>>  "If technologies are used in a way that is not accessibility supported, or if
>>  they are used in a non-conforming way, then they do not block the ability of
>>  users to access the rest of the page [...]"
>>
>>  So, in the example outlined below, one could argue that if a duplicate of a
>>  functionality is accessible then the functionality is effectively usable.
>>  However, one would also need to demonstrate the non-conforming functionality
>>  does not interfere with the overall accessibility of the page. For example,
>>  users may get stuck on the inaccessible piece when it is not apparent to them
>>  that there is an accessible alternative, in which case the page would not be
>>  usable altogether.
>>
>>  In conclusion, the mere existence of an accessible alternative for a
>>  functionality is probably not sufficient to demonstrate conformance with WCAG
>>  2; one would need to demonstrate non-interference too.
>>
>>  Question out of curiosity: how frequent are there situations in which the
>>  effort needed for all the necessary work-arounds to ensure that inaccessible
>>  components do not cause interference for the users would actually outweigh
>>  making these components directly accessible? It may be good to have real
>>  examples as a basis for the discussion.
>>
>>  Best,
>>  Shadi
>>
>>
>>  On 5.4.2012 18:46, Peter Korn wrote:
>>>  Eric,
>>>
>>>  As a start, it might be worth noting in introductory text the range of things
>>>  being covered by this methodology. In step 3 on selecting a representative
>>>  sample, we might again note that for complex web sites&  for large web
>>>  applications, there may "Exemplar functions" of a web app which should
>>>  definitely included, as distinct from "rarely used functions" - some of which
>>>  should be perhaps be included anyway as part of the sampling process (to not
>>>  ignore them entirely).
>>>
>>>  By the way, I thought of what might be a better example to use: a configuration
>>>  page/dialog for setting per-instance-overridable defaults (e.g. whether the
>>>  default currency is expressed in Dollars vs. Euros vs. Yen, which can be
>>>  expressly set each time by the user when they enter the currency in the
>>>  spreadsheet web-app). If that config page/dialog has an accessibility error
>>>  (e.g. an unlabeled combo-box), but the per-instance setting has no error (e.g.
>>>  the "set currency for this field" config page/dialog) - then... there is a good
>>>  argument to be made that the importance of the accessibility of the default
>>>  configuration setting isn't so great.
>>>
>>>  Ummm.... this raises another question... In Section 508 among other places we
>>>  have a notion that all functionality must be accessible, not necessarily all
>>>  ways of achieving all functionality. The example I made in the paragraph above
>>>  also connects to this question. It would be a clear WCAG conformance failure if
>>>  one part of a page failed one of the checkpoints. BUT... what about the
>>>  situation in which the failed part of the page was fully duplicated elsewhere.
>>>  This is a contrived edge-case for a single web page, but not at all unusual for
>>>  a complex web site or web application (after all, we already have the notion of
>>>  multiple-ways in WCAG). Is there any conformance distinction to be made between
>>>  a feature/aspect failure when it is the sole way of doing something vs. when it
>>>  is one of multiple ways and the other ways are accessible?
>>>
>>>
>>>  Regards,
>>>
>>>  Peter
>>>
>>>  On 4/5/2012 8:45 AM, Velleman, Eric wrote:
>>>>  Dear all,
>>>>
>>>>  What shall we say about auditing complex applications that are very large
>>>>  and offer enormous amounts of features (some important, some less
>>>>  important)? Example would be online document editors, online mail, online
>>>>  photo applications. Or should we point to ATAG and UAAG?
>>>>  Kindest regards,
>>>>
>>>>  Eric
>>>>
>>>
>>>  --
>>>  Oracle<http://www.oracle.com>
>>>  Peter Korn | Accessibility Principal
>>>  Phone: +1 650 5069522<tel:+1%20650%205069522>
>>>  500 Oracle Parkway | Redwood City, CA 94065
>>>  Green Oracle<http://www.oracle.com/commitment>  Oracle is committed to
>>>  developing practices and products that help protect the environment
>>
>
> --
> Oracle<http://www.oracle.com>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522<tel:+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> Green Oracle<http://www.oracle.com/commitment>  Oracle is committed to
> developing practices and products that help protect the environment

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)

Received on Friday, 6 April 2012 01:31:31 UTC