Установить accessibilityIdentifier в представлении заголовка пользовательского раздела таблицы для UIAutomation


Как установить идентификатор специальных возможностей в пользовательском представлении заголовка раздела в UITableView?

Для фона, поскольку ведение журнала дерева элементов табличного представления внутри UIAutomation создает плоский список ячеек таблицы (экземпляров UIATableCell), перемешанных с элементами группы таблиц (UIATableGroup), возможность идентификации групп облегчает идентификацию ячеек, принадлежащих этим группам (поскольку они возвращаются по порядку).

Если я установлю accessibilityIdentifier явно в пользовательском представлении, которое возвращается как представление заголовка раздела, я могу подтвердить, что свойство accessibilityIdentifier действительно установлено в этом представлении.

Вот этот метод, который подает пользовательский вид заголовка раздела (который, конечно же, отображается в моем фактическом табличном представлении):

 - (UIView *)tableView:(UITableView *)tableView 
viewForHeaderInSection:(NSInteger)sectionNumber
{
    UIView *headerView = [self someMethodToRetrieveHeaderView];

    // This line is logging that indeed, the accessibility identifier is set.
    NSLog(@"Header view accessibility identifier is: '%@' for section number: %d",
     headerView.accessibilityIdentifier, sectionNumber);         
    return headerView;
}

Проблема заключается в том, что когда я выполняю вызов logElementTree() в JavaScript в моем тесте UIAutomation против этого табличного представления, он возвращает мне элемент UIATableGroup, который имеет имя, производное от текстовое содержимое внутри этого представления заголовка раздела (т. е. возврат к эвристике UIAccessibilityLabel). Поскольку заголовок раздела содержит сегментированный элемент управления, я получаю несогласованные значения accessibilityLabel. Отсюда и мое желание обойти все это и присвоить явный идентификатор.

Как заставить мой собственный явный accessibilityIdentifier отображаться в качестве свойства имени UIATableGroup вместо этого?

1 2

1 ответ:

Вы должны убедиться, что возвращаемое представление также отвечает на isAccessibilityElement с помощью YES. Я смог решить эту проблему, экспериментируя с образцом приложения core data books, которое предоставляет Apple.

Я реализовал пользовательский вид следующим образом:

static int counter = 0;

@interface MyView : UIView
@end

@implementation MyView

- (NSString *)accessibilityIdentifier
{
    return [NSString stringWithFormat:@"Custom Identifier %d", counter++];
}

- (BOOL)isAccessibilityElement
{
    return YES;
}

@end

А затем я вернул его делегату табличного представления (который в данном случае является контроллером табличного представления):

- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
{
    MyView *v = [[MyView alloc] init];
    return v;
}

Я думаю, что происходит то, что инфраструктура доступности смотрит на представление заголовка и попытка захватить "идентификатор" первого подвида, который говорит, что это действительно элемент доступности. Таким образом, в вашем случае сегментированный элемент управления возвращает YES к isAccessibilityElement, так что это триггер для API доступности, что этот идентификатор является тем, который должен быть представлен.

Таким образом, решение состоит в том, чтобы убедиться, что UIView вы возвращаете как заголовок возвращает YES этому методу в дополнение к возвращению пользовательского идентификатора.