[WG: Accessibility] FW: Accessibility JIRA's Question re: Appropriate Priority Settings

[Richwine, Brian L]

Sorry if this is a duplicate, I didn't receive it from the list after I sent it the first time. -Brian

-----Original Message-----
From: Richwine, Brian L 
Sent: Wednesday, February 24, 2010 1:27 PM
To: 'Silverio, Gonzalo'; Mike Elledge; Sakai Accessibility WG
Subject: Accessibility JIRA's Question re: Appropriate Priority Settings

Hi,

I am concerned by an issue I saw in reading the comments on Jira SAK-11676 (http://jira.sakaiproject.org/browse/SAK-11676) relative to Ian's concern over the appropriate choice of "Blocker" for an accessibility Jira ticket priority.

The Accessibility Working Group's accessibility review reporting templates have a legend at the bottom listing priorities with definitions which uses the same terms (Blocker, Critical, etc.) as the Jira system uses. However, I notice that the definitions given for the terms on our reporting templates are considerably different than how the Jira guidelines define them.

The accessibility review's reporting templates define the priorities as follows:
  - Blocker: Issue will keep some/all users from being able to use this tool.
  - Critical: Issue will cause significant difficulty to some/all users and should be revised.
  - Major: Tool can be used successfully, but functionality will be significantly improved by fixing issue.
  - Minor: Indicates that this issue has a relatively minor impact.

In comparison, the Jira Documentation defines the priorities this way:
  - Blocker: Must be resolved for a release.
  - Critical: Most likely will be resolved for a release.
  - Major: Should be resolved for a release.
  - Minor: May be resolved for a release.
  - Trivial: Might be resolved for a release.

The domain's used for the definitions is considerably different. The review template's definitions relate to the user, while the Jira definitions either declare that an issue must be fixed, or require a prediction on the likely hood that the issue will be resolved for a release.

Given the difference, I can see how the developers and the accessibility working group have different views of the appropriateness of the selected priority level. Since the accessibility working group's definition for "Blocker" includes "will keep some ... users", I can understand how it has been chosen for many accessibility issues. 

I have to admit that the Jira Documentation's definitions for the priority levels don't make much sense to me. I understand the special role that "Blocker" has in the release process, and that the other priority levels stack up relative to each other in significance. I don't clearly understand how to map our understanding of the severity of an accessibility issue into the appropriate priority level as viewed from a Sakai developer/manager/etc. perspective. I doubt that any accessibility issue that doesn't affect every user would ever rightly be considered a "Blocker" in the Sakai 2.x community. 

IMHO we need to change the priority definitions as listed on the accessibility review reporting templates, and come up with some way to map our understanding of an accessibility issue's severity into the Jira system's priority levels. This way the Jira tickets we submit will be more appropriately prioritized and hopefully more credible in the Sakai community's eyes.

I am adding it to the agenda for tomorrow's teleconference. Please give this some thought, and even feel free to discuss this on the list before the meeting.

Thanks,
  Brian



-----Original Message-----
From: accessibility-bounces at collab.sakaiproject.org [mailto:accessibility-bounces at collab.sakaiproject.org] On Behalf Of Silverio, Gonzalo
Sent: Wednesday, February 24, 2010 11:09 AM
To: Mike Elledge
Cc: Sakai Accessibility WG
Subject: Re: [WG: Accessibility] outstanding issues report 3

Hey - many thanks Mike! This will help reconstruct things.

The maintenance team has been notified. I will reopen the following:

SAK-11199 Accessibility- Drop-down menus don't work with Screen Readers
(Global)
SAK-11200 Accessibility- Focus goes to top of page after pressing the
"cancel" button
SAK-11201 Accessibility- Instructions and visual symbols on page do not
match
SAK-11202 Accessibility- Cannot style text in FCK Editor when using screen
reader
SAK-11203 Accessibility- Granting permissions is confusing (Permissions
widget)
SAK-11406 Accessibility- Difficult to use without CSS (Page Order Helper)
SAK-11416 Accessibility- Access key is missing description (Polls)
SAK-11418 Accessibility- Missing access key description (Roster)
SAK-11419 Accessibility- Multiple links with the same name (Roster)
SAK-11420 Accessibility- Multiple links with the same name (Section Info)
SAK-11421 Accessibility- Multiple links with the same name (Syllabus)
SAK-11423 Accessibility- Frame titles missing (Chat)
SAK-11424 Accessibility- Text zoom issue (Chat)
SAK-11655 Accessibility- Text edit box has no label in FCK editor (Syllabus)
SAK-11656 Accessibility--FCK editor inaccessible
SAK-11660 Accessibility- JAWS users cannot tab to calendar in Gradebook
SAK-11661 Accessibility- Incorrect focus after editing (Gradebook)
SAK-11662 Accessibility- Table format and content unclear (Gradebook)
SAK-11663 Accessibility- Multiple links with the same name (Gradebook)
SAK-11664 Accessibility- Color is used to convey meaning (Gradebook)
SAK-11674 Accessibility- Edit field is unlabeled for FCK editor (Messages)
SAK-11679 Accessibility- Inaccessible dialogue box content (Wiki)
SAK-11680 Accessibility- Inaccessible flash object (Wiki)
SAK-11695 Accessibility--Problems using FCKEditor with a screen reader
SAK-11784 Accessibility- Revise tools to work in portal-based, non-iFrame
environment (Global)
SAK-1735 Accessibility--WYSIWYG Editor Focus
SAK-3427 Accessibility- Timed quiz extensions for students with disabilities
(Tests and Quizzes)
SAK-5046 Accessibility- Cannot tab to "Display to public" button on Add
Announcements Page
SAK-8233 Accessibility- Retain focus after changing tab location in
Preferences > Customize Tabs


    -Gonzalo


On 2/24/10 10:51 AM, "Mike Elledge" <elledge at msu.edu> wrote:

> Hi Gonzalo--
> 
> Thanks for doing this. It's really important and I'm glad you jumped on it.
> 
> I noticed, too, a large number of closed Accessibility Jiras soley
> because they cited prior versions of Sakai and had not been updated. In
> retrospect I wished I'd mentioned it so it could be nipped in the bud.
> 
> At any rate, you may want to ask the maintenance team to reopen them or
> (yecchh!) go into Jira and do it.
> 
> I've attached them. I couldn't figure out how to put them into a
> spreadsheet or word doc, but I thought it would be helpful to have them
> in one place. Sorry. :^(
> 
> Mike
> 
> Silverio, Gonzalo wrote:
>> Hi everyone,
>> 
>> Third report on working towards the goal of an accessibility bug free 2.7
>> release. See below for requests for clarification, lists of patches
>> submitted. Any input that clarifies issues listed in this and the other 2
>> reports is crucial to work getting done on them.
>> 
>> NOTE: I have ran across accessibility issues that simply have been closed by
>> the maintenance team. For example:
>> 
>> http://jira.sakaiproject.org/browse/SAK-11201
>> 
>> I will inform the maintenance team to refrain from doing this, as we are
>> working on these issues for 2.7
>> 
>> Thanks!
>> 
>>     -Gonzalo

_______________________________________________
accessibility mailing list
accessibility at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/accessibility

TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"