Re: Discussion: Applications

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