E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Meacham, Steve - FSA, Kansas City, MO
Date: Thu, Mar 05 2015 11:29AM
Subject: Presenting tabular data in visually non-tabular ways
No previous message | Next message →

I'm seeing this pattern more and more often: rows of data presented that could/should/would have traditionally been in a table with well-defined columns, but now presented as more of a blob of text. For example:

Assigned
Due 3/1/2015

Farm #12345 - 2,500 Acres
Montgomery County, Michigan
Approver: Jonathan McCormick

Started
Due 5/10/2015

Farm #2345 - 1,200 Acres
Montgomery County, Michigan
Approver: Jonathan McCormick

Competed
Due 5/15/2015

Farm #45689 - 450 Acres
Montgomery County, Michigan
Approver: Randy Smith

Approved
Due 6/1/2015

Farm #3214 - 12,450 Acres
Montgomery County, Michigan
Approver: Julia Bartosky


Visually, this actually seems to work. If you were trying to pick something from a list of items, all the necessary distinctives are there, positioned consistently to allow quickly scanning through the rows with our eyes. There are even in-line labels for non-self-evident data elements.

I don't believe that this works so well for users of AT, such as single-line refreshable Braille, or screen readers. How can such a user 'scan' the information, looking at one column-equivalent of data (Approver, for example, in the example above)?

What is our response, as both UX and Accesibility professionals?

Steve Meacham
FSA Section 508 Coordinator
Office: +1 (816) 926-1942
Call or Text: +1 (202) 455-USDA (8732)





This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

From: Birkir R. Gunnarsson
Date: Thu, Mar 05 2015 12:14PM
Subject: Re: Presenting tabular data in visually non-tabular ways
← Previous message | Next message →

If a table is the most semantically appropriate element for data, that
data should be set up as a table, not doing so would be a violation of
WCAG 1.3.1
If it looks like a table, is presented as a table and has visual
characteristics of a table with at least well-defined column headers,
that needs to be set up as a table with all required markup (marking
up column header cells and, if appropriate, rowheader cells).
If the faux table only has two columns and makes sense when linearized
I would not call this out, but when you have more than two columns,
tables do not linearize well and relevant information is easily lost
to users of screen readers if the datastructure markup is missing.
ARIA can be used to fix problems such as missing row or column headers
and, in extreme cases, can even be applied to existing containers to
create a grid from scratch, though that is quite frankly a bit silly.
So, yes, I would absolutely call those patterns out under WCAG 1.3.1
Cheers


On 3/5/15, Meacham, Steve - FSA, Kansas City, MO
< = EMAIL ADDRESS REMOVED = > wrote:
> I'm seeing this pattern more and more often: rows of data presented that
> could/should/would have traditionally been in a table with well-defined
> columns, but now presented as more of a blob of text. For example:
>
> Assigned
> Due 3/1/2015
>
> Farm #12345 - 2,500 Acres
> Montgomery County, Michigan
> Approver: Jonathan McCormick
>
> Started
> Due 5/10/2015
>
> Farm #2345 - 1,200 Acres
> Montgomery County, Michigan
> Approver: Jonathan McCormick
>
> Competed
> Due 5/15/2015
>
> Farm #45689 - 450 Acres
> Montgomery County, Michigan
> Approver: Randy Smith
>
> Approved
> Due 6/1/2015
>
> Farm #3214 - 12,450 Acres
> Montgomery County, Michigan
> Approver: Julia Bartosky
>
>
> Visually, this actually seems to work. If you were trying to pick something
> from a list of items, all the necessary distinctives are there, positioned
> consistently to allow quickly scanning through the rows with our eyes.
> There are even in-line labels for non-self-evident data elements.
>
> I don't believe that this works so well for users of AT, such as single-line
> refreshable Braille, or screen readers. How can such a user 'scan' the
> information, looking at one column-equivalent of data (Approver, for
> example, in the example above)?
>
> What is our response, as both UX and Accesibility professionals?
>
> Steve Meacham
> FSA Section 508 Coordinator
> Office: +1 (816) 926-1942
> Call or Text: +1 (202) 455-USDA (8732)
>
>
>
>
>
> This electronic message contains information generated by the USDA solely
> for the intended recipients. Any unauthorized interception of this message
> or the use or disclosure of the information it contains may violate the law
> and subject the violator to civil or criminal penalties. If you believe you
> have received this message in error, please notify the sender and delete the
> email immediately.
> > > >


--
Work hard. Have fun. Make history.

From: Cliff Tyllick
Date: Thu, Mar 05 2015 8:35PM
Subject: Re: Presenting tabular data in visually non-tabular ways
← Previous message | Next message →

Steve, I agree with Birker that structure needs to be coded into the content.

Heading and list elements could be used to create that structure, but in the content I see so many instances of repeated words that it screams for a table.

I can imagine that the presentation without a table would be appropriate when an individual set of results is presented. Still, it would need markup as a list—perhaps as a definition list—at the very least. In visually skimming the list, I perceive semantic relationships. Those relationships must also be perceivable to people who cannot see.

Cliff Tyllick
Texas Department of Assistive and Rehabilitative Services

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Mar 5, 2015, at 11:14 AM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> If a table is the most semantically appropriate element for data, that
> data should be set up as a table, not doing so would be a violation of
> WCAG 1.3.1
> If it looks like a table, is presented as a table and has visual
> characteristics of a table with at least well-defined column headers,
> that needs to be set up as a table with all required markup (marking
> up column header cells and, if appropriate, rowheader cells).
> If the faux table only has two columns and makes sense when linearized
> I would not call this out, but when you have more than two columns,
> tables do not linearize well and relevant information is easily lost
> to users of screen readers if the datastructure markup is missing.
> ARIA can be used to fix problems such as missing row or column headers
> and, in extreme cases, can even be applied to existing containers to
> create a grid from scratch, though that is quite frankly a bit silly.
> So, yes, I would absolutely call those patterns out under WCAG 1.3.1
> Cheers
>
>
> On 3/5/15, Meacham, Steve - FSA, Kansas City, MO
> < = EMAIL ADDRESS REMOVED = > wrote:
>> I'm seeing this pattern more and more often: rows of data presented that
>> could/should/would have traditionally been in a table with well-defined
>> columns, but now presented as more of a blob of text. For example:
>>
>> Assigned
>> Due 3/1/2015
>>
>> Farm #12345 - 2,500 Acres
>> Montgomery County, Michigan
>> Approver: Jonathan McCormick
>>
>> Started
>> Due 5/10/2015
>>
>> Farm #2345 - 1,200 Acres
>> Montgomery County, Michigan
>> Approver: Jonathan McCormick
>>
>> Competed
>> Due 5/15/2015
>>
>> Farm #45689 - 450 Acres
>> Montgomery County, Michigan
>> Approver: Randy Smith
>>
>> Approved
>> Due 6/1/2015
>>
>> Farm #3214 - 12,450 Acres
>> Montgomery County, Michigan
>> Approver: Julia Bartosky
>>
>>
>> Visually, this actually seems to work. If you were trying to pick something
>> from a list of items, all the necessary distinctives are there, positioned
>> consistently to allow quickly scanning through the rows with our eyes.
>> There are even in-line labels for non-self-evident data elements.
>>
>> I don't believe that this works so well for users of AT, such as single-line
>> refreshable Braille, or screen readers. How can such a user 'scan' the
>> information, looking at one column-equivalent of data (Approver, for
>> example, in the example above)?
>>
>> What is our response, as both UX and Accesibility professionals?
>>
>> Steve Meacham
>> FSA Section 508 Coordinator
>> Office: +1 (816) 926-1942
>> Call or Text: +1 (202) 455-USDA (8732)
>>
>>
>>
>>
>>
>> This electronic message contains information generated by the USDA solely
>> for the intended recipients. Any unauthorized interception of this message
>> or the use or disclosure of the information it contains may violate the law
>> and subject the violator to civil or criminal penalties. If you believe you
>> have received this message in error, please notify the sender and delete the
>> email immediately.
>> >> >> >
>
> --
> Work hard. Have fun. Make history.
> > >

From: Sailesh Panchang
Date: Fri, Mar 06 2015 7:35AM
Subject: Re: Presenting tabular data in visually non-tabular ways
← Previous message | Next message →

I have always suggested use of 2-column data tables with column
header cells (if present) and row header cells marked up as TH for
name->value pairs .
This is important when one can visually discern the semantic
relationship between data cells.
A screen reader user might wish to go down the first column and simply
review the attributes and not be concerned with the values for the
moment.
Or,it is easy to go down the list of attributes to a particular one
and then check its value.
Or, one can move down col#2 using table navigation and have the label
automatically announced by the SR.
Consider a case where the same set of attributes is repeated for
different subjects (farms / accounts / student etc.) on the page and
the UI design requires a 2-column representation for everysubject.

Failure to mark up row header cells as TH or with scope=row) (or other
method) is a violation as the semantic relation is not
programmatically determinable or _available in text_.
Using dl-dt-dd is alright but if not my first recommendation.
Some believe there are more critical issues that need to be addressed
and this one is not high on the priority. I completely discount this
reasoning.
Thanks,
Sailesh


On 3/5/15, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
> Steve, I agree with Birker that structure needs to be coded into the
> content.
>
> Heading and list elements could be used to create that structure, but in the
> content I see so many instances of repeated words that it screams for a
> table.
>
> I can imagine that the presentation without a table would be appropriate
> when an individual set of results is presented. Still, it would need markup
> as a list—perhaps as a definition list—at the very least. In visually
> skimming the list, I perceive semantic relationships. Those relationships
> must also be perceivable to people who cannot see.
>
> Cliff Tyllick
> Texas Department of Assistive and Rehabilitative Services
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its
> fault.
>
>> On Mar 5, 2015, at 11:14 AM, Birkir R. Gunnarsson
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> If a table is the most semantically appropriate element for data, that
>> data should be set up as a table, not doing so would be a violation of
>> WCAG 1.3.1
>> If it looks like a table, is presented as a table and has visual
>> characteristics of a table with at least well-defined column headers,
>> that needs to be set up as a table with all required markup (marking
>> up column header cells and, if appropriate, rowheader cells).
>> If the faux table only has two columns and makes sense when linearized
>> I would not call this out, but when you have more than two columns,
>> tables do not linearize well and relevant information is easily lost
>> to users of screen readers if the datastructure markup is missing.
>> ARIA can be used to fix problems such as missing row or column headers
>> and, in extreme cases, can even be applied to existing containers to
>> create a grid from scratch, though that is quite frankly a bit silly.
>> So, yes, I would absolutely call those patterns out under WCAG 1.3.1
>> Cheers
>>
>>
>> On 3/5/15, Meacham, Steve - FSA, Kansas City, MO
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>> I'm seeing this pattern more and more often: rows of data presented that
>>> could/should/would have traditionally been in a table with well-defined
>>> columns, but now presented as more of a blob of text. For example:
>>>
>>> Assigned
>>> Due 3/1/2015
>>>
>>> Farm #12345 - 2,500 Acres
>>> Montgomery County, Michigan
>>> Approver: Jonathan McCormick
>>>
>>> Started
>>> Due 5/10/2015
>>>
>>> Farm #2345 - 1,200 Acres
>>> Montgomery County, Michigan
>>> Approver: Jonathan McCormick
>>>
>>> Competed
>>> Due 5/15/2015
>>>
>>> Farm #45689 - 450 Acres
>>> Montgomery County, Michigan
>>> Approver: Randy Smith
>>>
>>> Approved
>>> Due 6/1/2015
>>>
>>> Farm #3214 - 12,450 Acres
>>> Montgomery County, Michigan
>>> Approver: Julia Bartosky
>>>
>>>
>>> Visually, this actually seems to work. If you were trying to pick
>>> something
>>> from a list of items, all the necessary distinctives are there,
>>> positioned
>>> consistently to allow quickly scanning through the rows with our eyes.
>>> There are even in-line labels for non-self-evident data elements.
>>>
>>> I don't believe that this works so well for users of AT, such as
>>> single-line
>>> refreshable Braille, or screen readers. How can such a user 'scan' the
>>> information, looking at one column-equivalent of data (Approver, for
>>> example, in the example above)?
>>>
>>> What is our response, as both UX and Accesibility professionals?
>>>
>>> Steve Meacham
>>> FSA Section 508 Coordinator
>>> Office: +1 (816) 926-1942
>>> Call or Text: +1 (202) 455-USDA (8732)
>>>
>>>
>>>
>>>
>>>
>>> This electronic message contains information generated by the USDA solely
>>> for the intended recipients. Any unauthorized interception of this
>>> message
>>> or the use or disclosure of the information it contains may violate the
>>> law
>>> and subject the violator to civil or criminal penalties. If you believe
>>> you
>>> have received this message in error, please notify the sender and delete
>>> the
>>> email immediately.
>>> >>> >>> >>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> > > > >

From: Jonathan C Cohn
Date: Fri, Mar 06 2015 8:32AM
Subject: Re: Presenting tabular data in visually non-tabular ways
← Previous message | Next message →

How would you distinguish a two column output from a definition It sounds to me like the functionality of what you are describing is actually a definition list.

Thanks,
> On Mar 6, 2015, at 09:35, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
>
> I have always suggested use of 2-column data tables with column
> header cells (if present) and row header cells marked up as TH for
> name->value pairs .
> This is important when one can visually discern the semantic
> relationship between data cells.
> A screen reader user might wish to go down the first column and simply
> review the attributes and not be concerned with the values for the
> moment.
> Or,it is easy to go down the list of attributes to a particular one
> and then check its value.
> Or, one can move down col#2 using table navigation and have the label
> automatically announced by the SR.
> Consider a case where the same set of attributes is repeated for
> different subjects (farms / accounts / student etc.) on the page and
> the UI design requires a 2-column representation for everysubject.
>
> Failure to mark up row header cells as TH or with scope=row) (or other
> method) is a violation as the semantic relation is not
> programmatically determinable or _available in text_.
> Using dl-dt-dd is alright but if not my first recommendation.
> Some believe there are more critical issues that need to be addressed
> and this one is not high on the priority. I completely discount this
> reasoning.
> Thanks,
> Sailesh
>
>
> On 3/5/15, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
>> Steve, I agree with Birker that structure needs to be coded into the
>> content.
>>
>> Heading and list elements could be used to create that structure, but in the
>> content I see so many instances of repeated words that it screams for a
>> table.
>>
>> I can imagine that the presentation without a table would be appropriate
>> when an individual set of results is presented. Still, it would need markup
>> as a list—perhaps as a definition list—at the very least. In visually
>> skimming the list, I perceive semantic relationships. Those relationships
>> must also be perceivable to people who cannot see.
>>
>> Cliff Tyllick
>> Texas Department of Assistive and Rehabilitative Services
>>
>> Sent from my iPhone
>> Although its spellcheck often saves me, all goofs in sent messages are its
>> fault.
>>
>>> On Mar 5, 2015, at 11:14 AM, Birkir R. Gunnarsson
>>> < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> If a table is the most semantically appropriate element for data, that
>>> data should be set up as a table, not doing so would be a violation of
>>> WCAG 1.3.1
>>> If it looks like a table, is presented as a table and has visual
>>> characteristics of a table with at least well-defined column headers,
>>> that needs to be set up as a table with all required markup (marking
>>> up column header cells and, if appropriate, rowheader cells).
>>> If the faux table only has two columns and makes sense when linearized
>>> I would not call this out, but when you have more than two columns,
>>> tables do not linearize well and relevant information is easily lost
>>> to users of screen readers if the datastructure markup is missing.
>>> ARIA can be used to fix problems such as missing row or column headers
>>> and, in extreme cases, can even be applied to existing containers to
>>> create a grid from scratch, though that is quite frankly a bit silly.
>>> So, yes, I would absolutely call those patterns out under WCAG 1.3.1
>>> Cheers
>>>
>>>
>>> On 3/5/15, Meacham, Steve - FSA, Kansas City, MO
>>> < = EMAIL ADDRESS REMOVED = > wrote:
>>>> I'm seeing this pattern more and more often: rows of data presented that
>>>> could/should/would have traditionally been in a table with well-defined
>>>> columns, but now presented as more of a blob of text. For example:
>>>>
>>>> Assigned
>>>> Due 3/1/2015
>>>>
>>>> Farm #12345 - 2,500 Acres
>>>> Montgomery County, Michigan
>>>> Approver: Jonathan McCormick
>>>>
>>>> Started
>>>> Due 5/10/2015
>>>>
>>>> Farm #2345 - 1,200 Acres
>>>> Montgomery County, Michigan
>>>> Approver: Jonathan McCormick
>>>>
>>>> Competed
>>>> Due 5/15/2015
>>>>
>>>> Farm #45689 - 450 Acres
>>>> Montgomery County, Michigan
>>>> Approver: Randy Smith
>>>>
>>>> Approved
>>>> Due 6/1/2015
>>>>
>>>> Farm #3214 - 12,450 Acres
>>>> Montgomery County, Michigan
>>>> Approver: Julia Bartosky
>>>>
>>>>
>>>> Visually, this actually seems to work. If you were trying to pick
>>>> something
>>>> from a list of items, all the necessary distinctives are there,
>>>> positioned
>>>> consistently to allow quickly scanning through the rows with our eyes.
>>>> There are even in-line labels for non-self-evident data elements.
>>>>
>>>> I don't believe that this works so well for users of AT, such as
>>>> single-line
>>>> refreshable Braille, or screen readers. How can such a user 'scan' the
>>>> information, looking at one column-equivalent of data (Approver, for
>>>> example, in the example above)?
>>>>
>>>> What is our response, as both UX and Accesibility professionals?
>>>>
>>>> Steve Meacham
>>>> FSA Section 508 Coordinator
>>>> Office: +1 (816) 926-1942
>>>> Call or Text: +1 (202) 455-USDA (8732)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This electronic message contains information generated by the USDA solely
>>>> for the intended recipients. Any unauthorized interception of this
>>>> message
>>>> or the use or disclosure of the information it contains may violate the
>>>> law
>>>> and subject the violator to civil or criminal penalties. If you believe
>>>> you
>>>> have received this message in error, please notify the sender and delete
>>>> the
>>>> email immediately.
>>>> >>>> >>>> >>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> >> >> >> >>
> > > Best wishes,

Jonathan

From: Jonathan Avila
Date: Fri, Mar 06 2015 9:20AM
Subject: Re: Presenting tabular data in visually non-tabular ways
← Previous message | Next message →

> ou are describing is actually a definition list

I agree. HTML 5 redefined the definiition list markup to be name value pairs markup

Jonathan
SSB BART Group

> On Mar 6, 2015, at 7:34 AM, Jonathan C Cohn < = EMAIL ADDRESS REMOVED = > wrote:
>
> ou are describing is actually a definition list

From: Sailesh Panchang
Date: Fri, Mar 06 2015 9:33AM
Subject: Re: Presenting tabular data in visually non-tabular ways
← Previous message | No next message

A glossary of terms is a definition list.
The term in the first row is unrelated to the term in the next.
On the other hand:
Street address, Home type (single / townhome), lot size, Sq ft size,
Year built, etc. are all attributes for a home.
Now one can represent this data in a 2-col tabular layout for
different homes one below the other. This will suit a page with such
data for a single home too.
A data table is better than a DL, no?
Note, often the label in the 1st col is styled distinctly and there
may or may not be grid lines. In a glossary there are never any grid
lines.
Thanks,
Sailesh


On 3/6/15, Jonathan C Cohn < = EMAIL ADDRESS REMOVED = > wrote:
> How would you distinguish a two column output from a definition It sounds
> to me like the functionality of what you are describing is actually a
> definition list.
>
> Thanks,
>> On Mar 6, 2015, at 09:35, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> I have always suggested use of 2-column data tables with column
>> header cells (if present) and row header cells marked up as TH for
>> name->value pairs .
>> This is important when one can visually discern the semantic
>> relationship between data cells.
>> A screen reader user might wish to go down the first column and simply
>> review the attributes and not be concerned with the values for the
>> moment.
>> Or,it is easy to go down the list of attributes to a particular one
>> and then check its value.
>> Or, one can move down col#2 using table navigation and have the label
>> automatically announced by the SR.
>> Consider a case where the same set of attributes is repeated for
>> different subjects (farms / accounts / student etc.) on the page and
>> the UI design requires a 2-column representation for everysubject.
>>
>> Failure to mark up row header cells as TH or with scope=row) (or other
>> method) is a violation as the semantic relation is not
>> programmatically determinable or _available in text_.
>> Using dl-dt-dd is alright but if not my first recommendation.
>> Some believe there are more critical issues that need to be addressed
>> and this one is not high on the priority. I completely discount this
>> reasoning.
>> Thanks,
>> Sailesh
>>
>>
>> On 3/5/15, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
>>> Steve, I agree with Birker that structure needs to be coded into the
>>> content.
>>>
>>> Heading and list elements could be used to create that structure, but in
>>> the
>>> content I see so many instances of repeated words that it screams for a
>>> table.
>>>
>>> I can imagine that the presentation without a table would be appropriate
>>> when an individual set of results is presented. Still, it would need
>>> markup
>>> as a list—perhaps as a definition list—at the very least. In visually
>>> skimming the list, I perceive semantic relationships. Those relationships
>>> must also be perceivable to people who cannot see.
>>>
>>> Cliff Tyllick
>>> Texas Department of Assistive and Rehabilitative Services
>>>
>>> Sent from my iPhone
>>> Although its spellcheck often saves me, all goofs in sent messages are
>>> its
>>> fault.
>>>
>>>> On Mar 5, 2015, at 11:14 AM, Birkir R. Gunnarsson
>>>> < = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>> If a table is the most semantically appropriate element for data, that
>>>> data should be set up as a table, not doing so would be a violation of
>>>> WCAG 1.3.1
>>>> If it looks like a table, is presented as a table and has visual
>>>> characteristics of a table with at least well-defined column headers,
>>>> that needs to be set up as a table with all required markup (marking
>>>> up column header cells and, if appropriate, rowheader cells).
>>>> If the faux table only has two columns and makes sense when linearized
>>>> I would not call this out, but when you have more than two columns,
>>>> tables do not linearize well and relevant information is easily lost
>>>> to users of screen readers if the datastructure markup is missing.
>>>> ARIA can be used to fix problems such as missing row or column headers
>>>> and, in extreme cases, can even be applied to existing containers to
>>>> create a grid from scratch, though that is quite frankly a bit silly.
>>>> So, yes, I would absolutely call those patterns out under WCAG 1.3.1
>>>> Cheers
>>>>
>>>>
>>>> On 3/5/15, Meacham, Steve - FSA, Kansas City, MO
>>>> < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> I'm seeing this pattern more and more often: rows of data presented
>>>>> that
>>>>> could/should/would have traditionally been in a table with well-defined
>>>>> columns, but now presented as more of a blob of text. For example:
>>>>>
>>>>> Assigned
>>>>> Due 3/1/2015
>>>>>
>>>>> Farm #12345 - 2,500 Acres
>>>>> Montgomery County, Michigan
>>>>> Approver: Jonathan McCormick
>>>>>
>>>>> Started
>>>>> Due 5/10/2015
>>>>>
>>>>> Farm #2345 - 1,200 Acres
>>>>> Montgomery County, Michigan
>>>>> Approver: Jonathan McCormick
>>>>>
>>>>> Competed
>>>>> Due 5/15/2015
>>>>>
>>>>> Farm #45689 - 450 Acres
>>>>> Montgomery County, Michigan
>>>>> Approver: Randy Smith
>>>>>
>>>>> Approved
>>>>> Due 6/1/2015
>>>>>
>>>>> Farm #3214 - 12,450 Acres
>>>>> Montgomery County, Michigan
>>>>> Approver: Julia Bartosky
>>>>>
>>>>>
>>>>> Visually, this actually seems to work. If you were trying to pick
>>>>> something
>>>>> from a list of items, all the necessary distinctives are there,
>>>>> positioned
>>>>> consistently to allow quickly scanning through the rows with our eyes.
>>>>> There are even in-line labels for non-self-evident data elements.
>>>>>
>>>>> I don't believe that this works so well for users of AT, such as
>>>>> single-line
>>>>> refreshable Braille, or screen readers. How can such a user 'scan' the
>>>>> information, looking at one column-equivalent of data (Approver, for
>>>>> example, in the example above)?
>>>>>
>>>>> What is our response, as both UX and Accesibility professionals?
>>>>>
>>>>> Steve Meacham
>>>>> FSA Section 508 Coordinator
>>>>> Office: +1 (816) 926-1942
>>>>> Call or Text: +1 (202) 455-USDA (8732)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This electronic message contains information generated by the USDA
>>>>> solely
>>>>> for the intended recipients. Any unauthorized interception of this
>>>>> message
>>>>> or the use or disclosure of the information it contains may violate the
>>>>> law
>>>>> and subject the violator to civil or criminal penalties. If you believe
>>>>> you
>>>>> have received this message in error, please notify the sender and
>>>>> delete
>>>>> the
>>>>> email immediately.
>>>>> >>>>> >>>>> >>>>
>>>>
>>>> --
>>>> Work hard. Have fun. Make history.
>>>> >>>> >>>> >>> >>> >>> >>>
>> >> >> >
>
>
> Best wishes,
>
> Jonathan
>
>
>
> > > >