Re: Improvements to Use Case System (Was: Request to re-open issue 131)

Thank you Smylers, for the excellent suggestions. Replies are in-thread.

On 12/21/11 9:18 AM, Smylers wrote:
> Charles Pritchard sent the following reply directly to me, but has said
> I'm welcome to follow it up on the list:
>
>> On Dec 19, 2011, at 2:04 AM, Smylers<Smylers@stripey.com>  wrote:
>>
>>>> I know I've had a difficult time with the "use case" system.
>>> In what way? It seems to make sense to me that features are only
>>> designed once it's clear what problems they are solving.
>> In that the problems we are solving are from the WCAG checklists and
>> system accessibility inspectors. When we state that an item on WCAG is
>> not met, or a field in the system a11y API is left empty, those
>> specific technical issues are not accepted as use cases.
> Well an item on a list created by somebody else is a level of
> indirection away from an end-user use case (in that ticking off items in
> a list isn't _inherently_ useful; it's only useful because the items on
> the list are themselves useful).
>
> But if those checklists were created base on actual use cases then
> clearly it could save this working group time to simply adopt them
> wholesale rather than re-evaluate each one from first principles.
>
> The chairs have been encouraging working group members to raise bugs on
> the decision-making process itself. If you'd like items on WCAG
> checklists to be automatically considered as sufficient use cases (by
> proxy) then how about raising a bug on the process suggesting exactly
> that? That would seem a better approach than tying this to Issue 131).


That sounds quite nice: what particular section would this bug report 
fall under?

ATAG, ARIA and WCAG have been built on real-world use cases and are 
intended to solve real-world needs.

The UAAG asks that vendors provide "Standard programming interfaces, to 
enable interaction with assistive technologies", and it is suggested 
that "People who want to encourage their existing user agent developer 
to improve accessibility in future versions can refer the user agent 
vendor to UAAG".
http://www.w3.org/WAI/intro/uaag.php


>> When we bring up real-world products, ones on the market or in
>> development, we are told that authors should have programmed them in a
>> different language (SVG).
> That would seem to be an issue of granularity. Currently use cases are
> considered for HTML as a whole (or indeed the open web platform as a
> whole), so they are met if there is some way of achieving them in HTML.
> After all, if something can be done in HTML then anybody can choose to
> do it that way.
>
> You've elsewhere referred to 'canvas developers', a group of people I
> for one hadn't previously realized existed. If it's important for use
> cases to be met with specific sub-systems of HTML rather than HTML as a
> whole then again you could raise a bug suggesting this and explaining
> why it is important and which sub-systems we should support in this way.


SVG is considered as a separate sub-system, though it is also considered 
in the scope of HTML (mainly through CSS cross-overs). I believe Canvas 
should be treated in a similar manner.

Many Web Apps APIs are considered on their own merit, independently of 
HTML. In many ways, Canvas is a Web Apps API; whereas SVG is a markup 
language.

I'm happy to post bug suggestions for these two items, but I do not know 
which section they would fall under.
https://www.w3.org/Bugs/Public/enter_bug.cgi


-Charles

Received on Thursday, 22 December 2011 22:22:31 UTC