- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 17 Jun 2015 16:00:05 -0400
- To: Eric Eggert <ee@w3.org>
- Cc: wai-eo-editors@w3.org, Shadi Abou-Zahra <shadi@w3.org>
Hello Eric, Thanks for your responses. Here are my thoughts: Right, on that HTML 4 page (http://www.w3.org/TR/html4/struct/tables.html#non-visual-rendering) I am specifically referring to: "Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate". The moment content is marked up as a data table, it is a two-dimension representation. By its very nature, it permits functionality that is not possible in content marked up as a list i.e. single dimension. So if "12 February, Waltz with Strauss, Main Hall" is a list item, one cannot navigate down just the date column or the event column or venue column. If this indeed were marked up as a list, sighted users and screen reader users will be able to access only the intended functionality i.e. read an entire list item one by one. For a screen reader user, going down any of the 3 columns is like just going down a list of dates, events or venues. These are not marked up as 3 separate lists but as a data table for a very precise reason: to expose data relationships through presentation in a manner that offers functionality that a single dimension list cannot. In a table, visually one can run down a column and also be imbibing referential data from an adjacent cell so the content makes complete sense. A screen reader user cannot do so unless row header cell is marked up as a header. In a sales invoice with item code, item description, rate, quantity and amount as column headers, if I navigate down say, the rate or quantity column, I'd like the item code or description announced as a reference point. I agree in a bank transaction table with date, transaction type, description, debit/credit and amount as five columns, neither the date or transaction type or even description may be unique or distinct to identify a row. Yet, marking up one of those with scope=row provides the needed reference. Sure it is not the only meaningful "header" for a row, but it serves as a very useful reference point and thus as a row header. I believe this principle is ensconced in the H63 test:Check that all td elements that act as headers for other elements have a scope attribute. The cells in a column act as row header or a reference point. When this relationship is not strong / unique or not in the first column (general convention for row headers), the scope attribute is very handy. Relevant normative definitions: relationships: meaningful associations between distinct pieces of content presentation: rendering of the content in a form to be perceived by users functionality: processes and outcomes achievable through user action Basically a data table contains record(s) of data and every cell represents an attribute of the record. In a table one at most times wants to understand / compare / look for a cell value and a column / row header provides the necessary reference or identity. Actually in a simple table pulled from a database too, it may not be possible to uniquely identify every record simply by its primary key and one may need to use primary+secondary key to do so. So in a table of bank transactions too header-id method that exposes 2-3 cells as a row header may be really useful. But this may be impractical to do for a simple table. At the minimum, exposing the date or tran type or description is a compromise. On the WAI-EO tables tutorial page, reference to "smallness" of the table is prominent: "The following table of concerts has the cells in the first row marked up using the <th> element. This is only acceptable because it is such a small table and the data itself is distinctly different in each column, so that the relationship between the header and data cells is evident". And you added: "Smallness of the table is not the reasoning behind this. The reasoning is having data in each row/column that “is descriptive on its own and unambiguous”. So does this mean that a developer must always look and examine the data to verify if it is distinct and "unambiguous" as you put it and then determine the markup? So if the data is pulled from a database or represents a set of transactions, then a table with the same set of column headings might need row headers for one set of data and not for another because one fails to meet the test of "unambiguous"? And what if the one that meets the test has 15 rows in 3 columns? Is that big or small? You misinterpret my words when you say : "Single row/col header tables are just a special form of simple tables. We had them all the time, this is not something that HTML5 introduced". I did not say HTML5 introduced them but remarked that I have observed the trend to separate them out as a class of simple tables has gained prominence since the intro of HTML5. So previously, if an accessibility tester noticed that a data table did not have row headers and col#2 was the ideal candidate for row headers, H63 (td scope=row) was the fix. Now developers may think twice because scope cannot be used with TD cells in HTML5 and they may resist the idea of marking col#2 cells as TH. Placing role=rowheader will expose it as header cells to screen readers. Role=rowheader on a TD says "I am a row header" to AT and that is what scope=row on TD does too, right? If it is wrong for a TD cell to be exposed as a header cell to user agent, does switching one attribute with another make it less wrong? Thanks very much, Sailesh Panchang On 6/16/15, Eric Eggert <ee@w3.org> wrote: > Hi Sailesh, > > see comment inline. > > On 16 Jun 2015, at 16:14, Sailesh Panchang wrote: > >> Eric and EO-WG, >> Sorry I am bringing this up again but it disturbs me every time I come >> across it. >> Reference: the 3-col table with Date, Event, Venue on >> http://www.w3.org/WAI/tutorials/tables/one-header/ >> I do not agree with the reasoning: due to the smallness of the table, >> it is alright not to have row headers marked up. >> Even for the 3x4 table I'd like to know the date as I navigate down >> col#3. >> And who gets to decide what is small? A content author may say, in his >> opinion, a 3x12 table is small. >> One can argue the table illustrated on table with 2 headers on the >> WAI page too is small. > > Smallness of the table is not the reasoning behind this. The reasoning > is having data in each row/column that “is descriptive on its own and > unambiguous”. Basically that means that each row/column could be > interpreted correctly if there was no markup applied as well, for > example: > > 12 February, Waltz with Strauss, Main Hall > > This is descriptive and and unambiguous. It the table had twelve dates > on it in that format, it would still meet the reasoning for simple > tables. > >> A simple data table usually has row and column headers. >> So I do not believe a 3+ col table can not have row headers marked up. > > Of course it can, but it must not. As said, this has nothing to do with > the number of columns but with the identification of the content. > >> Account transactions on a bank's website often do not have row >> headers marked up and that is problematic for me as a user. > > I think that bank statements won’t fit the description above, maybe > they would for the simplest case, like: > > John Doe, Rent, USD -1000 > > but not if there are additional information and/or interactive functions > (see details) in there. > >> Maybe the date or transaction type or description col may serve as a >> suitable row header and can be marked up with scope=row. >> HTML 4 recognized this reality and has an explicit note to this effect >> in the specs. > > I guess you refer to the second sample in this section: > http://www.w3.org/TR/html4/struct/tables.html#non-visual-rendering > > (If you don’t, please point me to the example, please.) > > Note that they don’t use row headings in the example although I’d > argue that the data in the table is _not_ unambiguous (J. Dinnen, 5, > Decaf, Yes) and thus the name should be marked up as a row cell. > >> Alas HTML5 does not allow scope on TD cells but that may be a mere >> validation issue not a SC 4.1.1 issue. So I still recommend use of >> scope=row on TD. > > And the tutorials suggest that as well, yet it is not exactly required > by WCAG 2.0, for example it uses this technique: > http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/H63.html > >> So this is a dangerous path. >> I have seen the "1-dimension table with single row / col of headerss" >> being mentioned since the introduction of HTML5. >> Before that all discussion of data tables only mentioned simple tables >> and complex / irregular tables. > > Single row/col header tables are just a special form of simple tables. > We had them all the time, this is not something that HTML5 introduced. > In contrary, I found many people struggling implementing single row/col > header tables in practice (they are also used in newspapers, books and > other media). They do not want to use a th in the body of the table as > that has often styling attached to it and they don’t want any data > item emphasized in a row. A header cell would automatically be > emphasized. > >> >> Recommendation: do away with the category of "Tables with one header >> ". >> Sighted users see the column headers and may associate the date or >> event as a row header mentally as it serves as a reference point or >> row identifier although it may not be marked up as a header cell or >> appear bold / centered. >> The content author has to decide which column logically is the row >> identifier and mark it up as TH or TD scope=row (H63). > > All examples on the page DO pass the test in H63. The recommendation is > based on it. Quote from H63: > >> 1. Check that all th elements have a scope attribute. > > Check. > >> 2. Check that all td elements that act as headers for other elements >> have a scope attribute. > > This is not applicable, as there are no cells that act as headers. > >> 3. Check that all scope attributes have the value row, col, rowgroup, >> or colgroup. > > All scope attributes have the value "col" (or "row"). > > >> Only if there is no visible row header as in a calendar grid or a >> column header row in a 2-column table with name-value pairs of data, >> that table can certainly have a single table row or column marked up >> as header cells. >> So I believe the recommendation on above referred page stems from the >> constraint introduced in HTML5 that prohibits use of scope attribute >> on a TD cell. Understandably UI designers may not want a TH in the >> middle of a table if col#1 is not the row header column. > >> The reasoning that prohibits scope on TD may make a lot of sense >> technically or in computer science terms but if a vision-impaired >> user cannot determine the row identifier for a data table as he >> navigates a data table column while his sighted peers can, I think the >> content is inaccessible and fails as noted in F91. > > If there is no visible row header (because all data is considered to be > on the same level and one cell does not make sense with all the others > involved as well), then this is not a failure according to H91. Quote > from there: > >> 1. headers marked up with table header (th) elements >> 2. scope attributes on th for tables with more than a single row or >> column of table headers. >> 3. scope attributes on th for tables with more than a single row or >> column of table headers. >> 4. headers and data cells associated using headers and id attributes >> 5. headers marked up as td elements with the scope attribute >> 6. headers marked up with ARIA role attributes rowheader or >> columnheader >> >> If _all_ checks #1 - #4 are false, then this failure condition applies >> and the content fails the Success Criterion. > > According to my understanding all headers do have th elements (as the > individual rows in the table body are headerless), and they have the > scope attribute. Thus it doesn’t fail those two checks and thus is not > failing this failure. > > I welcome continued discussion on this, and think the misunderstanding > is that I (and, based on the discussion with EO, the Group) think there > are legitimate reasons for headerless rows/columns _in special > circumstances_ and you think there aren’t. > > WCAG WG has also vetted the tutorial and didn’t see anything to not be > conforming to WCAG 2.0. There have been no comments on this at all. > > I will check back with EO and WCAG WG chairs to see how we can address > this issue, probably the advice in the WCAG techniques has to change, > maybe we need to make changes to the tutorial, maybe both. > > Best, > Eric > > >> Thanks, >> Sailesh Panchang >> Principal Accessibility Consultant >> Deque Systems Inc >> Phone 703-225-0380 ext 105 >> Mobile: 571-344-1765 >> >> >> On 1/7/15, Eric Eggert <ee@w3.org> wrote: >>> Hi Sailesh, >>> >>> On 6 Jan 2015, at 15:36, Sailesh Panchang wrote: >>> >>>> I thought we are giving objective suggestions to meet WCAG 2 >>>> compliance not based on opinions but on documented specs and facts. >>> >>> Sure, the foundations for the tutorials are >>> >>> - WCAG 2.0 and Techniques >>> - HTML5, CSS and other W3C specifications >>> - Established best practices >>> - The aim to communicate solutions in a clear and less complicated >>> manner to web developers as a primary audience. >>> >>>> If the doctype is HTML4, td with scope is valid and breaks nothing. >>> >>> I’m not arguing with that, but it is a technique that is not often >>> used. HTML is describing the content and I am sure a lot of people >>> would >>> argue that a td with a scope is used as a heading and therefor the td >>> is >>> semantically the wrong choice and a th needs to be used when scope is >>> used. (And that is reflected by the changes to HTML5.) >>> >>>> Please refer to the reasoning in the HTML4 specs . >>>> In fact TH in the second column may not be agreeable to some UI >>>> designers (even with HTML5) because they may not want centered and >>>> bolded content in the middle of a table. >>> >>> The HTML is about semantics, not about the visual style. This >>> argument >>> could be easy interpreted as “If a UI designers doesn’t want >>> their >>> main heading too big they are free to use an h4”. The th is the >>> semantically correct element to use, the visual appeal should never >>> inform the usage of elements to keep the content and presentation >>> separated. >>> >>>> Using CSS to do away the >>>> visual effect of TH negates the proper use of TH. So when it does >>>> not suit UI design, using TD and scope may be the way to go ... >>>> sure >>>> it may not be valid in HTML5 but that does not fail SC 4.1.1 or any >>>> WCAG2 SC. >>> >>> I do not agree here. Usually the centered style is unwanted, a bold >>> style is usually applied. If it is data like other data in that row >>> and >>> thus has doesn’t need any visual or semantic differentiation, it >>> should be a plain td (without a scope attribute). If the developer >>> doesn’t see the need to style the cell differently it may sometimes >>> not be a header cell to begin with. >>> >>> If it is indeed a heading for that column, it should be styled >>> differently to enable easier parsing by visual users. >>> >>> I see that the scope for td is mentioned in failure [F91] and >>> technique >>> [H63] but it doesn’t feel appropriate to me, considering [G115]. I >>> will check back with EOWG and WCAG WG to see what to do here. For me >>> this looks like a technique from a time where CSS wasn’t widely >>> available and th styling wasn’t really easy to change. >>> >>> Considering the audience of the tutorials, we can expect them to >>> write >>> modern code and knowing their way around CSS. I’m still not >>> convinced >>> that this is a technique that should be thought and thus recommend >>> for >>> the future in the tutorials. >>> >>> I will bring this to EOWG and see if and how we want to cover this. >>> >>> >>>>>> During the creation of the tutorials we tested with a variety of >>>>>> different >>screen readers and configurations. Almost every screen >>>>>> reader interpreted >>adjacent header cells as headings for the >>>>>> current header cell. >>>>>> We decided after long discussions in EOWG that we’d like to >>>>>> recommend >>scope in all but the most simple instances. ... scope >>>>>> never makes the table >>less accessible. >>>> Besides informing FS, I had also filed a bug with nvaccess.org. Both >>>> SRs (current and previous version) work as expected now. Telling >>>> developers to put in more markup than what's required based on >>>> testing with SRs that had bugs is not helpful for developers or >>>> testers. Would you fail a table if it had only TH and no scope? How >>>> do >>>> you define small or 'most simple' table? >>>> Thanks for your consideration; I hope the comments are reviewed by >>>> more within EO-WG. >>> >>> We had people using the tables with current Jaws and NVDA and they >>> reported an increase in accessibility when using scope. I can check >>> back >>> with them, but in general we agreed to use scope and recommend people >>> to >>> use scope on most tables. I like to convey clear actionable >>> accessibility instructions, as they are easy to follow. If people >>> need >>> to think a lot about how to approach something, they’ll likely do >>> what >>> is less effort and/or complexity. Even if it is wrong. >>> >>> (If I had to decide, scope or headers and IDs would be required on >>> every >>> table as the concepts are fairly simple and if developers used it >>> throughout their projects they wouldn’t be confused from what table >>> complexity it is necessary. But I am not making decisions on this ;-) >>> >>> As for “most simple tables”, those have easily distinguishable >>> data >>> like “Date – Event name – City” and don’t have too many >>> columns. >>> >>> I will bring this to EOWG once again, although we had a lot of >>> discussions before. >>> >>> Best, Eric >>> >>> [F91]: http://www.w3.org/TR/WCAG20-TECHS/F91.html >>> [H63]: http://www.w3.org/TR/WCAG20-TECHS/H63.html >>> [G115]: http://www.w3.org/TR/WCAG20-TECHS/G115.html >>> >>>> Sailesh Panchang >>>> >>>> >>>> On 1/6/15, Eric Eggert <ee@w3.org> wrote: >>>>> Hi Sailesh, >>>>> >>>>> the majority of your amendment was covered by my earlier response, >>>>> just >>>>> a quick note on one aspect here: >>>>> >>>>> On 2 Jan 2015, at 14:27, Sailesh Panchang wrote: >>>>> >>>>>> Amendment to item #5 sent on Dec 31: >>>>>> "The only instance where scope is needed in a simple data table is >>>>>> where the row identifier is not in the first column like in >>>>>> "Example >>>>>> 4: Table with an offset column of header cells". >>>>>> should read: >>>>>> "The only instance where scope is needed in a simple data table is >>>>>> where the row identifier is not in the first column like in >>>>>> "Example >>>>>> 4: Table with an offset column of header cells if they are marked >>>>>> up >>>>>> as TD and not TH. It is valid in HTML4 to use TD with the scope >>>>>> attribute and there is an explicit remark about this in the HTML4 >>>>>> guidance doc". >>>>> >>>>> While the use of scope in on a TD element seems possible in HTML4, >>>>> I >>>>> wouldn’t consider this as best practice. With HTML5, scope >>>>> isn’t >>>>> allowed on TD elements anymore, so I don’t think including this >>>>> is >>>>> too >>>>> relevant and would complicate the message that we try to convey. >>>>> >>>>> Thanks again for your suggestions, >>>>> Eric >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sailesh Panchang >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Eric Eggert >>>>> Web Accessibility Specialist >>>>> Web Accessibility Initiative (WAI) at Wold Wide Web Consortium >>>>> (W3C) >>>>> >>> >>> >>> >>> >>> -- >>> >>> Eric Eggert >>> Web Accessibility Specialist >>> Web Accessibility Initiative (WAI) at Wold Wide Web Consortium (W3C) > > > > > -- > > Eric Eggert > Web Accessibility Specialist > Web Accessibility Initiative (WAI) at Wold Wide Web Consortium (W3C) > >
Received on Wednesday, 17 June 2015 20:00:34 UTC