Accessibility of RT for screen reader users?

Hello all,
Thanks for your comments on my long list of questions yesterday. I’m going
to take today and set up RT on our Debian server, just to see how well it
works. As I do, one final question comes to mind: how well does RT work
with screen readers?

For those unfamiliar, a screen reader does basically what it says on the
box: it is a program that speaks, using synthesized speech, what’s on the
screen. It uses standard system commands augmented with a set of its own
commands to read just about everything–emails, webpages, spreadsheets,
documents, menus, etc. Different screen readers do different amounts of
guessing if the OS/current application fails to provide information, but
they all work best when whatever you’re using them to access complies with
standards and best practices.

In this case, I’m wondering how compliant RT’s webpages are with web
accessibility standards. I’m visually impaired, so use a screen reader
(NVDA, www.nvda-project.org) to do all my work. I’m the only one who will
be using RT here that needs a screen reader, but as it’s my job to
administer the system, I have to be able to use it reasonably well.
OSTicket has several major problems in this area, and, while I could
usually get around them, they made things slower and more frustrating than
they needed to be.

If anyone has any experience with web accessibility and happens to know how
well RT works with common screen readers, I’d love your thoughts.
Specifically, I’m looking for the basics–label tags for form fields, table
titles, image descriptions using the alt attribute, use of headings and/or
landmarks to facilitate easy navigation, accessible widgets like menus or
dialogs, and so on. I’ll find out soon first-hand how well RT does at
these, and I did have a quick look through the demo site, but if anyone has
input I’d love to hear it. Thanks.

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

Hi Alex

While I don’t have much experience with web accessibility I do run a
network of public PCs that includes NVDA installed on those PCs, so I
jumped onto one of them to do a quick test of the RT web pages with NVDA
active. Bearing in mind that I don’t know what is supposed to be good and
bad for these sorts of things, here are my observations, based on the list
of your basics:

  • label tags for form fields: yes. You have to mouse over for them to be
    read
  • table titles - When I opened a ticket listing (for example, by clicking
    on a search) the page opened and the first thing NVDA said was “table of x
    rows and Y columns”. It also read the table title (e.g. “Found 1 Ticket”).
    However it did not automatically read column titles, I had to mouse over
    them.
  • image descriptions use alt attribute - yes, but actually a bit annoying.
    At the top right hand corner of every RT page is the Best Practical Logo so
    every page change one of the things it read was the Logo’s alt attribute.
    It felt redundant really quickly!
  • use of headings/landmarks - yes, RT divides tickets display pages into
    sections and the headings are not only in enlarged fonts but different
    sections have color-coded headings. For example, “The Basics” and “Custom
    Fields” is in bright red, the “People” section is in light blue, “Dates” is
    in magenta, etc. So depending on the level of your visual impairment that
    may be useful.
  • accessible widgets like menus or dialogs: menus = yes, dialogs = no.
    There are no popups. Also, the menus are all dropdowns, so nothing visible
    in the menu until you click on it. Clicking on a menu heading does not
    change page, it just opens the menu. Not sure if it is relevant but you can
    configure custom field selection boxes in multiple ways, so for example you
    can make them a dropdown box, or a selectable list, that sort of thing.

One other observation for the web interface: in ticket listings, RT
abbreviates dates (so “Aug” for August" etc) which took a bit of getting
used to when NVDA read out the abbreviation when I moused over it.

Hope that helps!
ChrisOn Thu, 25 Aug 2016 at 00:10 Alex Hall ahall@autodist.com wrote:

Hello all,
Thanks for your comments on my long list of questions yesterday. I’m going
to take today and set up RT on our Debian server, just to see how well it
works. As I do, one final question comes to mind: how well does RT work
with screen readers?

For those unfamiliar, a screen reader does basically what it says on the
box: it is a program that speaks, using synthesized speech, what’s on the
screen. It uses standard system commands augmented with a set of its own
commands to read just about everything–emails, webpages, spreadsheets,
documents, menus, etc. Different screen readers do different amounts of
guessing if the OS/current application fails to provide information, but
they all work best when whatever you’re using them to access complies with
standards and best practices.

In this case, I’m wondering how compliant RT’s webpages are with web
accessibility standards. I’m visually impaired, so use a screen reader
(NVDA, www.nvda-project.org) to do all my work. I’m the only one who will
be using RT here that needs a screen reader, but as it’s my job to
administer the system, I have to be able to use it reasonably well.
OSTicket has several major problems in this area, and, while I could
usually get around them, they made things slower and more frustrating than
they needed to be.

If anyone has any experience with web accessibility and happens to know
how well RT works with common screen readers, I’d love your thoughts.
Specifically, I’m looking for the basics–label tags for form fields, table
titles, image descriptions using the alt attribute, use of headings and/or
landmarks to facilitate easy navigation, accessible widgets like menus or
dialogs, and so on. I’ll find out soon first-hand how well RT does at
these, and I did have a quick look through the demo site, but if anyone has
input I’d love to hear it. Thanks.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

Thanks for testing. My only concerns are mousing over things to get them to read, and whether the colored items are true headings?

For mousing, I wonder if tab will do the same? That is, if you tab from field to field, will NVDA announce the field label as focus changes to the field? I never use a mouse, so moving the pointer over a field isn’t something I think of testing.

The colored items: are those headings in look only, or actual h tags? That is, when you’re on the page with them, does pressing the h key move you to each one in turn?> On Aug 24, 2016, at 19:18, Chris McClement chrisis@bosberaad.com wrote:

Hi Alex

While I don’t have much experience with web accessibility I do run a network of public PCs that includes NVDA installed on those PCs, so I jumped onto one of them to do a quick test of the RT web pages with NVDA active. Bearing in mind that I don’t know what is supposed to be good and bad for these sorts of things, here are my observations, based on the list of your basics:

  • label tags for form fields: yes. You have to mouse over for them to be read
  • table titles - When I opened a ticket listing (for example, by clicking on a search) the page opened and the first thing NVDA said was “table of x rows and Y columns”. It also read the table title (e.g. “Found 1 Ticket”). However it did not automatically read column titles, I had to mouse over them.
  • image descriptions use alt attribute - yes, but actually a bit annoying. At the top right hand corner of every RT page is the Best Practical Logo so every page change one of the things it read was the Logo’s alt attribute. It felt redundant really quickly!
  • use of headings/landmarks - yes, RT divides tickets display pages into sections and the headings are not only in enlarged fonts but different sections have color-coded headings. For example, “The Basics” and “Custom Fields” is in bright red, the “People” section is in light blue, “Dates” is in magenta, etc. So depending on the level of your visual impairment that may be useful.
  • accessible widgets like menus or dialogs: menus = yes, dialogs = no. There are no popups. Also, the menus are all dropdowns, so nothing visible in the menu until you click on it. Clicking on a menu heading does not change page, it just opens the menu. Not sure if it is relevant but you can configure custom field selection boxes in multiple ways, so for example you can make them a dropdown box, or a selectable list, that sort of thing.

One other observation for the web interface: in ticket listings, RT abbreviates dates (so “Aug” for August" etc) which took a bit of getting used to when NVDA read out the abbreviation when I moused over it.

Hope that helps!
Chris

On Thu, 25 Aug 2016 at 00:10 Alex Hall ahall@autodist.com wrote:
Hello all,
Thanks for your comments on my long list of questions yesterday. I’m going to take today and set up RT on our Debian server, just to see how well it works. As I do, one final question comes to mind: how well does RT work with screen readers?

For those unfamiliar, a screen reader does basically what it says on the box: it is a program that speaks, using synthesized speech, what’s on the screen. It uses standard system commands augmented with a set of its own commands to read just about everything–emails, webpages, spreadsheets, documents, menus, etc. Different screen readers do different amounts of guessing if the OS/current application fails to provide information, but they all work best when whatever you’re using them to access complies with standards and best practices.

In this case, I’m wondering how compliant RT’s webpages are with web accessibility standards. I’m visually impaired, so use a screen reader (NVDA, www.nvda-project.org) to do all my work. I’m the only one who will be using RT here that needs a screen reader, but as it’s my job to administer the system, I have to be able to use it reasonably well. OSTicket has several major problems in this area, and, while I could usually get around them, they made things slower and more frustrating than they needed to be.

If anyone has any experience with web accessibility and happens to know how well RT works with common screen readers, I’d love your thoughts. Specifically, I’m looking for the basics–label tags for form fields, table titles, image descriptions using the alt attribute, use of headings and/or landmarks to facilitate easy navigation, accessible widgets like menus or dialogs, and so on. I’ll find out soon first-hand how well RT does at these, and I did have a quick look through the demo site, but if anyone has input I’d love to hear it. Thanks.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

The coloured items are links but they are not tags. Their attributes
are defined using CSS classes.

I tried tabbing through the page and you have to tab through every item in
every menu before you get to the body of the ticket. Once in the body of
the ticket tabbing jumps from link to link, and tickets typically have many
of these.

Of interest may be RT’s built-in keyboard shortcuts:

While there are shortcuts to navigate search results as well as some basic
actions (like commenting) there do not appear to be shortcuts for
navigating headings within a ticket.On Thu, 25 Aug 2016 at 15:05 Alex Hall ahall@autodist.com wrote:

Thanks for testing. My only concerns are mousing over things to get them
to read, and whether the colored items are true headings?

For mousing, I wonder if tab will do the same? That is, if you tab from
field to field, will NVDA announce the field label as focus changes to the
field? I never use a mouse, so moving the pointer over a field isn’t
something I think of testing.

The colored items: are those headings in look only, or actual h tags? That
is, when you’re on the page with them, does pressing the h key move you to
each one in turn?

Sent from my iPhone

On Aug 24, 2016, at 19:18, Chris McClement chrisis@bosberaad.com wrote:

Hi Alex

While I don’t have much experience with web accessibility I do run a
network of public PCs that includes NVDA installed on those PCs, so I
jumped onto one of them to do a quick test of the RT web pages with NVDA
active. Bearing in mind that I don’t know what is supposed to be good and
bad for these sorts of things, here are my observations, based on the list
of your basics:

  • label tags for form fields: yes. You have to mouse over for them to be
    read
  • table titles - When I opened a ticket listing (for example, by clicking
    on a search) the page opened and the first thing NVDA said was “table of x
    rows and Y columns”. It also read the table title (e.g. “Found 1 Ticket”).
    However it did not automatically read column titles, I had to mouse over
    them.
  • image descriptions use alt attribute - yes, but actually a bit annoying.
    At the top right hand corner of every RT page is the Best Practical Logo so
    every page change one of the things it read was the Logo’s alt attribute.
    It felt redundant really quickly!
  • use of headings/landmarks - yes, RT divides tickets display pages into
    sections and the headings are not only in enlarged fonts but different
    sections have color-coded headings. For example, “The Basics” and “Custom
    Fields” is in bright red, the “People” section is in light blue, “Dates” is
    in magenta, etc. So depending on the level of your visual impairment that
    may be useful.
  • accessible widgets like menus or dialogs: menus = yes, dialogs = no.
    There are no popups. Also, the menus are all dropdowns, so nothing visible
    in the menu until you click on it. Clicking on a menu heading does not
    change page, it just opens the menu. Not sure if it is relevant but you can
    configure custom field selection boxes in multiple ways, so for example you
    can make them a dropdown box, or a selectable list, that sort of thing.

One other observation for the web interface: in ticket listings, RT
abbreviates dates (so “Aug” for August" etc) which took a bit of getting
used to when NVDA read out the abbreviation when I moused over it.

Hope that helps!
Chris

On Thu, 25 Aug 2016 at 00:10 Alex Hall ahall@autodist.com wrote:

Hello all,
Thanks for your comments on my long list of questions yesterday. I’m
going to take today and set up RT on our Debian server, just to see how
well it works. As I do, one final question comes to mind: how well does RT
work with screen readers?

For those unfamiliar, a screen reader does basically what it says on the
box: it is a program that speaks, using synthesized speech, what’s on the
screen. It uses standard system commands augmented with a set of its own
commands to read just about everything–emails, webpages, spreadsheets,
documents, menus, etc. Different screen readers do different amounts of
guessing if the OS/current application fails to provide information, but
they all work best when whatever you’re using them to access complies with
standards and best practices.

In this case, I’m wondering how compliant RT’s webpages are with web
accessibility standards. I’m visually impaired, so use a screen reader
(NVDA, www.nvda-project.org) to do all my work. I’m the only one who
will be using RT here that needs a screen reader, but as it’s my job to
administer the system, I have to be able to use it reasonably well.
OSTicket has several major problems in this area, and, while I could
usually get around them, they made things slower and more frustrating than
they needed to be.

If anyone has any experience with web accessibility and happens to know
how well RT works with common screen readers, I’d love your thoughts.
Specifically, I’m looking for the basics–label tags for form fields, table
titles, image descriptions using the alt attribute, use of headings and/or
landmarks to facilitate easy navigation, accessible widgets like menus or
dialogs, and so on. I’ll find out soon first-hand how well RT does at
these, and I did have a quick look through the demo site, but if anyone has
input I’d love to hear it. Thanks.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

Thanks, shortcuts always help. :slight_smile: Just to be clear, the h key isn’t a
website-specific shortcut, it’s built into NVDA and Jaws. Web authors need
do nothing more than use h tags, and screen readers will be able to jump to
those headings. CSS styling isn’t enough to tell the screen reader that a
given span or div is supposed to be a heading. However, RT doesn’t need to
add heading jumping commands to make the navigation work, it just needs to
add h tags where, visually, they should be anyway.On Thu, Aug 25, 2016 at 5:08 PM, Chris McClement chrisis@bosberaad.com wrote:

The coloured items are links but they are not tags. Their attributes
are defined using CSS classes.

I tried tabbing through the page and you have to tab through every item in
every menu before you get to the body of the ticket. Once in the body of
the ticket tabbing jumps from link to link, and tickets typically have many
of these.

Of interest may be RT’s built-in keyboard shortcuts: https://
bestpractical.com/blog/2016/7/keyboard-shortcuts

While there are shortcuts to navigate search results as well as some basic
actions (like commenting) there do not appear to be shortcuts for
navigating headings within a ticket.

On Thu, 25 Aug 2016 at 15:05 Alex Hall ahall@autodist.com wrote:

Thanks for testing. My only concerns are mousing over things to get them
to read, and whether the colored items are true headings?

For mousing, I wonder if tab will do the same? That is, if you tab from
field to field, will NVDA announce the field label as focus changes to the
field? I never use a mouse, so moving the pointer over a field isn’t
something I think of testing.

The colored items: are those headings in look only, or actual h tags?
That is, when you’re on the page with them, does pressing the h key move
you to each one in turn?

Sent from my iPhone

On Aug 24, 2016, at 19:18, Chris McClement chrisis@bosberaad.com wrote:

Hi Alex

While I don’t have much experience with web accessibility I do run a
network of public PCs that includes NVDA installed on those PCs, so I
jumped onto one of them to do a quick test of the RT web pages with NVDA
active. Bearing in mind that I don’t know what is supposed to be good and
bad for these sorts of things, here are my observations, based on the list
of your basics:

  • label tags for form fields: yes. You have to mouse over for them to be
    read
  • table titles - When I opened a ticket listing (for example, by clicking
    on a search) the page opened and the first thing NVDA said was “table of x
    rows and Y columns”. It also read the table title (e.g. “Found 1 Ticket”).
    However it did not automatically read column titles, I had to mouse over
    them.
  • image descriptions use alt attribute - yes, but actually a bit
    annoying. At the top right hand corner of every RT page is the Best
    Practical Logo so every page change one of the things it read was the
    Logo’s alt attribute. It felt redundant really quickly!
  • use of headings/landmarks - yes, RT divides tickets display pages into
    sections and the headings are not only in enlarged fonts but different
    sections have color-coded headings. For example, “The Basics” and “Custom
    Fields” is in bright red, the “People” section is in light blue, “Dates” is
    in magenta, etc. So depending on the level of your visual impairment that
    may be useful.
  • accessible widgets like menus or dialogs: menus = yes, dialogs = no.
    There are no popups. Also, the menus are all dropdowns, so nothing visible
    in the menu until you click on it. Clicking on a menu heading does not
    change page, it just opens the menu. Not sure if it is relevant but you can
    configure custom field selection boxes in multiple ways, so for example you
    can make them a dropdown box, or a selectable list, that sort of thing.

One other observation for the web interface: in ticket listings, RT
abbreviates dates (so “Aug” for August" etc) which took a bit of getting
used to when NVDA read out the abbreviation when I moused over it.

Hope that helps!
Chris

On Thu, 25 Aug 2016 at 00:10 Alex Hall ahall@autodist.com wrote:

Hello all,
Thanks for your comments on my long list of questions yesterday. I’m
going to take today and set up RT on our Debian server, just to see how
well it works. As I do, one final question comes to mind: how well does RT
work with screen readers?

For those unfamiliar, a screen reader does basically what it says on the
box: it is a program that speaks, using synthesized speech, what’s on the
screen. It uses standard system commands augmented with a set of its own
commands to read just about everything–emails, webpages, spreadsheets,
documents, menus, etc. Different screen readers do different amounts of
guessing if the OS/current application fails to provide information, but
they all work best when whatever you’re using them to access complies with
standards and best practices.

In this case, I’m wondering how compliant RT’s webpages are with web
accessibility standards. I’m visually impaired, so use a screen reader
(NVDA, www.nvda-project.org) to do all my work. I’m the only one who
will be using RT here that needs a screen reader, but as it’s my job to
administer the system, I have to be able to use it reasonably well.
OSTicket has several major problems in this area, and, while I could
usually get around them, they made things slower and more frustrating than
they needed to be.

If anyone has any experience with web accessibility and happens to know
how well RT works with common screen readers, I’d love your thoughts.
Specifically, I’m looking for the basics–label tags for form fields, table
titles, image descriptions using the alt attribute, use of headings and/or
landmarks to facilitate easy navigation, accessible widgets like menus or
dialogs, and so on. I’ll find out soon first-hand how well RT does at
these, and I did have a quick look through the demo site, but if anyone has
input I’d love to hear it. Thanks.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com